Is anything really new?
The fashion world, television and the IT landscape all have something in common. It often seems like we are seeing reruns: centralize versus decentralize; market proliferation versus market consolidation, privacy versus security, and standards versus innovations. Now, every time you turn around you hear about SOA. Does SOA really matter, or is it just another hard to explain three letter acronym?
First, I believe it does really matter, and that it is different. This article will be my first in an ongoing series related to what is new and different in SOA.
The first and most important point is the ability to align business initiatives and IT strategy. I have been involved in creating middleware products for over ten years. I remember being interviewed for an article entitled, “What keeps you up at night?” The article was written from the perspective of what kept CIO’s awake at night in 1999. I responded that CIOs were up all night worrying about whether their websites could withstand the barrage of hits at peak times, whether they were able to ensure that transactions were completed, whether they could commit to the database fast enough, and whether their outage would be front page news. (Remember when outages were news rather than the loss of personal information?) The interesting thing about the list was that it was all about technical issues, nothing about the business.
Another difference today is who is having the conversation. It’s not just the IT department. When you poll the audience and ask for a show of hands, there is always a mix of executives, line of business, and technical people in the room. There is often a group who sit in-between the business and technical side. So I am just as likely to talk to a business person as a CIO today.
So the answer to “what keeps you up at night?” is very different today than it was 8 years ago. Business issues carry more weight than the technical issues. And the technical issues are measured from the perspective of how they impact the business issues. The good news is that if we embrace the approach, SOA will enable us to create our systems in a way that lets technology enable rather than inhibit change. So how do we take advantage of this important difference?
How do we make sure we take advantage of this possibility in SOA?
• Be sure you keep the architecture in your service oriented architecture. It is about an approach, not about a tool or a product. Have a documented architecture. Establish a practical process that encourages, and in fact makes it easy for the developers to incorporate the architecture in their systems. An architecture that remains a blueprint on a shelf is not ever going to reap benefits.
• For every project, identify a specific short term achievable, measurable business goal. It should be something that can be stated in a sentence. Shorten the cycle by three days. Reduce the turnaround by 30 minutes. Reduce return rate by 5%. Stay away from goals like “keep the database available 99.9% of the time”, or “provide a better user interface”, or “provide online access to users.” A project might include these requirements, but they are not the business goals.
• Conduct a Business Architecture Roadmap Assessment for each project. That is, be sure that you balance your long term strategies with your short term needs. You need that short term goal we just identified above, but in each project, there are opportunities to use services that have already been created, and if necessary to create new services, but in ways that they can be used by other projects later. The perfect service is one that can support multiple processes, users or lines-of-business and be used in a way you never envisioned when you created it. To find these, start by looking for information and activities that are common across processes and organizations, or that span lines-of-business.
So to answer my own question – Yes, SOA does matter. And it really is different. But it is not something you purchase off the shelf. Today’s column concentrated on aligning your business initiatives and IT strategy. More about what makes SOA different in my next column.
