Service-Oriented Architecture (SOA) looks and sounds very technical. “Architecture” most certainly sounds very specialized. Anything “-Oriented” ranks right up there with “framework” as being steeped in mystery. And what’s a “Service?” It took the business community long enough to figure out what a process was. Now we’re supposed to know what a service is! No wonder SOA has been and still is an IT-driven initiative.
But should it be? IT is certainly involved; someone has to establish the infrastructure. However, should IT decide what services to develop and when? Shouldn’t the business, based on its goals and objectives, identify and put priorities on the services that will provide the most value to the business? So how do we get there from here?
IT-Driven SOA: History repeats itself
When object-oriented development entered the scene it was very IT-centric. Those of us that knew structured techniques thought it would be an easy transition; we were wrong. As the paradigm matured we saw more and more object- oriented design, object-oriented analysis, and eventually use cases. Now, the concept of use cases is fairly well understood by the business community.
Component-based solutions were a natural outcome of the maturing process of object-oriented development, as were message-based solutions. In all three cases, there was a significant technology perspective that can not be trivialized. The same holds true for SOA. In these situations a considerable amount of work must be done to prove not only that the new approach is viable but also that it provides value.
The business will not be distracted from their primary mission, running the business, by any new technology or new approach until they are convinced that it will provide business value. In fact, they probably won’t even notice it. IT must conduct the proof of concept, if I may call it that. It is up to IT to recognize that there is a new technology that is applicable to the business problem, prove the concept, and introduce it to the business community. And IT is in a perfect position to do so; they see what new technologies are on the horizon and they have visibility into just about every aspect of the business.
So it is no surprise that all of these paradigm shifts started out as IT-driven initiatives. We may understand why SOA is currently an IT-driven initiative. However, at the risk of insulting IT, I contend that unless the business decides what services to develop and when, all IT has developed is a really nice proof-of-concept.
That is not to say that SOA, the architectural perspective, has to wait for the business community to finally get a grasp of what SOA can do for them. Establishing SOA within the framework of an existing IT architecture requires planning, analysis, design and construction before the first service is even conceived of. IT has enough internal processes to prove the concept themselves. In fact, a “proof-of-concept” like that can be put into production helping to improve IT’s efficiency and effectiveness. But that is as far as it goes without business involvement.
Business-Driven Services Solution: The desired state
So the desired state is thus. While IT establishes and proves the services architecture, the business works across functional silos to identify and prioritize processes for automation; these processes are documented in the Process Architecture component of the Business Architecture. They uncover candidate services when they discover processes that are shared across business functions. The business community then determines the value that such services can bring to the table and they work with IT to determine the cost of developing the services. With this information in hand, the business community agrees upon what services to develop and when. Thus begins the Services Portfolio.
As the portfolio of services matures, the business community monitors its impact on the business. The results are fed into the governance program where decisions are made regarding the current set of initiatives, the IT strategy, various business plans, maybe the business architecture itself, or even the overall business strategy and business vision. Wherever adjustments are made, the cycle begins all over. If the business architecture changes, chances are the business processes change. If business processes change, the portfolio of services may change or, at the very least, reprioritization of the services under development occurs. In any case, the monitoring continues and, you guessed it, the whole governance cycle continues. The point is SOA is business-driven, not IT-driven; IT is the enabler. SOA is also governed just like any other part of the business.
That is the desired state. Nice theory, huh?
Maturity: Where we are now
If SOA started out as IT-driven initiatives and we want to mature our approach to the point of being business-driven, we have to know where we are on the maturity curve? Let’s start by defining maturity.Maturity models exist for just about everything imaginable. And I am sure that someone has done a scientific study, including surveys, of the maturity of the SOA market. However, I have a full-time job that does not include scientific studies so I ask you to take the following model for what it’s worth. If you come across one of those scientific models I encourage you to use it. For the purposes of this article, let’s assume the following definitions.
- Business-driven: This is the highest level of maturity whereby the business community leverages the business architecture to make sound business decisions regarding the Services Portfolio, sponsors and funds the development effort, and actively promotes the benefits across the enterprise.
- Value-driven: At this level, the business community makes well-intended decisions regarding what services to develop and when based on perceived business value.
- Business Involvement: This is the point in the maturity curve where IT is well aligned with the business, understands the business need, and is able to make value-added recommendations regarding candidate services. The business community makes the final decision but the recommendations are usually very good and the business decision is little more than a formality.
- Business Awareness: The business is aware that IT is implementing SOA and making services available. However, IT is making the decisions about what services to develop and to whom they are released based on its knowledge of the business.
- IT-driven: This is the lowest level of maturity whereby IT is in the early stages of implementing SOA, focused primarily on the architecture and the infrastructure, and developing a limited set of services for the purpose of proving the concept.
So where are we on the maturity curve? There are some enterprises that have made an active decision not to pursue SOA; perhaps it was a financial decision. For those that are pursuing SOA, it has been my observation that a select few are “approaching” the Business Involvement level while the majority is well behind. Saying that they are “approaching” Business Involvement means that IT is doing most of the heavy lifting and that they have to push the business community to get involved. When they mature a little more, and move “just beyond” Business Involvement, that is the point at which the business community will be actively and willingly involved. This is not to say that there aren’t some enterprises higher on the maturity curve. I just don’t have any personal experience with one that is.
Leveraging your business architecture: How we get there from here
Advancing along the SOA maturity curve is not a matter of time; death by natural causes is a matter of time. To advance along any maturity curve requires commitment. To advance your SOA maturity, business-related critical success factors must be met.
- Know why you are doing this. There could be any number of reasons for establishing SOA: transformation, standardization, modernization, flexibility, etc. Derive your rationale for implementing SOA from you business goals and objectives.
- IT and the business must be fully aligned. The business strategy and the IT strategy must be driven by the same set of goals and objectives. In so doing, your business architecture and IT architecture will be aligned.
- IT must gain the trust of the business community. In some cases this means IT resources are assigned to various business units; they live and breathe the business and are held accountable for ensuring that IT meets the needs of the business. These resources must understand the business architecture and how the IT architecture relates.
- Services must provide business value. Whether you are low on the maturity curve or high, know what value candidate services bring. If you can’t quantify the value, don’t develop the service. And the place to go to determine the value is (you guessed it) the business architecture. It will tell you what business functions are affected and to what degree. It will also tell you how many of the business goals and objectives it contributes to meeting.
- Governance is a must. Subject the performance of the business and the performance of IT to the same governance and oversight. Remember, IT is part of the business and must be treated as an equal partner is every business decision.
As always I close with Organizational Change Management. As SOA becomes business-driven, every service that is added to the portfolio changes the way the business community operates. The impact on the business must be managed effectively. It is the responsibility of the business sponsor to actively promote the benefits of the new service(s) and see to it that the change is managed effectively.
