SOA maturity model is a term that I coined in an attempt to help organizations define architectural guidelines and a process for achieving a greater level of maturity and predictability in their overall information technology (IT) architecture initiatives. The model described in this article is designed to enable your organization to identify itself on a scale of 1 to 5 (with 5 being the most advanced, or mature, level) in terms of architecture maturity. An iterative application of the SOA maturity model allows IT organizations to evolve to meet rapidly changing business needs in a cost- and time-effective manner. Using this model, I show how at each level of maturity you can achieve more architectural goals.
Importance of a Maturity Model
At lower levels of maturity, individual project teams define their own architecture using nonstandard techniques. These techniques lead to less-predictable and less-repeatable solutions that are difficult to manage and do not adapt to change. As the organization matures to Level 3 and 4, a strong Enterprise Architecture (EA) group presence emerges that acts like a governing body for architectural principles. Elements of a reusable architecture appear, and are flexible to the needs of each Line of Business (LOB) that it serves. This solution tends to be effective, provides some level of interoperability, and paves the path toward service orientation. I define a Level-5 organization as one that has implemented and been successful in its SOA initiatives. This type of organization has bought into the concepts and has evolved to the point of truly building and sharing services among the LOBs and maybe even with the customers, partners, suppliers, and possibly even competitors.
The SOA maturity model
The SOA Maturity Model is targeted at measuring the maturity in the SOA development process. I define the SOA maturity model with the same five steps outlined by CMM.
Figure 1. The SOA maturity model
Level 1: Initial
Organizations at the Initial SOA maturity model level are typically those in which no formal processes for architecture exist. There is no separation of architecture from projects. Typically, these organizations do not have an EA team; each project team, generally broken down by LOBs, works in a silo. The focus is on delivering an individual project.
The result of this level is unpredictable project schedules, budget overruns, and poor quality code that is typically not reusable and hard to maintain. Projects repeat the same tasks, thus increasing the cost of delivery and maintenance. At this level of maturity, or rather immaturity, IT tends to dictate business agility instead of the other way around.
Level 2: Repeatable
At this level, some elements of architecture efforts emerge. Project teams tend to define a reusable architecture that they use from one project to another. Informal paths of communication are established across project teams. However, because there is still little to no presence of an EA team, these levels of communications are ad hoc and chaotic. At this stage an EA team would help put structure to the chaos and foster the communications between the project teams.
The result is some level of reuse of architectural components. Ad hoc processes and chaotic lines of communication lead to some level of repeatability in architectural solutions, thus lowering the cost of delivery and the maintenance costs of software. This reduction is hardly significant from a dollar perspective.
The greatest advantage of this level of maturity is the realization of benefits that a structured process can lead too. Project teams are realizing the potential benefits of a more synergetic approach to software development. They realize that the can prevent the huge cost overruns, create a predictable software development schedule and improve the overall quality of the software. Advocates who are opening these ad hoc lines of communication across project teams can make a case to executives to gain sponsorship towards an EA organization (or at least a formal recognition for a greater architectural initiative).
Level 3: Defined
Level-3 organizations are typical organizations that have made some substantial investment in an EA initiative. A team is in place that is tasked with standardizing architecture elements. This team is responsible for creating a reference architecture, educating project teams on this architecture, and defining a governance and enforcement policy. Typically the EA teams tend to start with creating a set of technical components and frameworks and standardizing the use of these frameworks across project teams.
I suspect most Fortune 500 organizations fit into this level. The vision of organizations at this level is that this overseeing EA team can substantially reduce the cost of project delivery. However, the reality seems to be that EA teams lack the business knowledge and do not communicate well with the project teams serving each LOB.
EA team initiatives seem to cost more than the value they add. The single biggest cost that comes with an EA team is the ongoing cost of architecture maintenance. In today’s tough economy, as the core architecture team is moved back to delivering projects, the EA is typically not maintained, thus reducing its value and applicability. Another issue at this level is the tug-of-war between the project teams and the enterprise team. Project teams do not really respect or like the “prying eyes” of the EA team.
In my opinion, this level is a first step in recognizing the need for an SOA. EA efforts seem to fail, because they are typically not nimble enough to satisfy needs across LOBs. They need to realize that at the end of the day, they are serving a business. This recognition will eventually lead to their success and is what takes an organization to the next level of architectural maturity.
Level 4: Managed
This level of maturity is achieved when EA teams start defining a path to SOA. Today, every big organization has a group of architects talking about SOA. At the very least, these architects seem to recognize the value of and are trying to figure out an SOA strategy.
An organization can be classified as Level 4 if its SOA initiatives proactively seek by-in from project teams that serve the LOBs. The project teams and EA team need to work together to define the organization’s SOA, including the processes, technologies, and components. Governance and “reward” policies should be defined. Support levels need to be established with a clear understanding of whom to call when and for what. A framework for analysts to define services must be in place. How does an LOB or a project team identify potential services that it can expose or that it needs from another project team? Who is responsible for building and maintaining this service? Who pays for it? These are the types of questions the SOA plan at this level would answer.
It is important to realize that Level 4 has little to no short-term cost benefit. Getting to and executing Level 4 is a very costly effort for any organization. If done right, it leads organizations to Level 5 in the SOA maturity model. If done poorly, an organization will most likely drop to a Level 2, because the EA team will be disbanded or have little support from the business.
Level 5: Optimizing
Level 5 is nirvana. Architectural processes and policies are institutionalized, and there is a clear recognition of the value of services. A framework is in place for each team to expose and consume services. At this level, organizations can truly explore the value of SOA. They start figuring out how to exchange services with their business partners, suppliers, and customers.
Business service level re-use — not just technology component re-use — is core to the architecture in order to achieve maximum business agility. At this level, organizations see the cost and time benefits of having a more nimble IT organization that can quickly respond to business needs.
The key goal of this level is to define an end-point for your architecture initiatives. Without the vision of this level, organizations won’t be able to justify the costs of getting past Level 4.
Summary
Simply embarking on an SOA project is not always the best way to start. An organization must determine what the first steps are in its SOA initiatives. To be successful in implementing SOA in your organization, you first need to understand the IT landscape and overall architecture of your organization. The SOA maturity model is just that: a means of helping you assign a level of maturity to the IT architecture of your organization. When this assessment is complete, you’ll have the information you need to determine the best path to an SOA for your organization.
In applying this model, EA groups can determine what services they need to provide to individual LOBs. In addition, consulting and out-sourcing firms can use this model to build a list of services that they might want to add to their service offerings.
In the final article in this series, I will introduce a new methodology called Service Oriented Unified Process (SOUP) for building your SOA. This methodology is simply a different way of applying RUP and Extreme Programming as they are best suited for an SOA project.
