SOA

Service Oriented Architecture (SOA) Maturity Model

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 here 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. The model also helps pave your path to achieving a true Services Oriented Architecture (SOA), which is defined as a Level 5 on the maturity curve. 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. Members of staff may well visit visit party poker or have long lunches, but they will only do this on their own time and the organization itself will not be affected. 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.

This model applies to all aspects of a company’s IT architecture. It not only has a strong impact on the development side but is equally important to the physical, logical, deployment, and process architectures within the IT organization.

The SOA maturity model

The Capability Maturity Model is used to measure the maturity of the software development process at an organization. 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 shows the basic SOA maturity model:

Figure 1. The SOA maturity model

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. So what does this level of maturity really get you?

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. The EA team’s lack of domain knowledge is the big issue. Those EA teams that recognize this drawback will be successful. It is imperative that they do not consider themselves experts: 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.

This level of maturity comes with a lot of risk as well as a lot of benefit. In particular, 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, however, 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 instutionalized, 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. High standards and goals need to be clearly defined to achieve them. Without the vision of this level, organizations won’t be able to justify the costs of getting past Level 4.

Characteristics and impacts of each level

Now you’ve seen the five levels of the SOA maturity model. Table 1 describes at a high level the characteristics and impacts of each level of maturity.

Table 1. Overview of SOA maturity model levels
Table 1. Overview of SOA maturity model levels
Levels
Characteristics
Impacts
Level 1: Initial
  • No formal software-development process
  • Minimal documentation of architecture
  • No communication across project teams
  • No formal software-development process
  • Minimal documentation of architecture
  • No communication across project teams
Level 2: Repeatable
  • Some level of architectural documentation
  • Architecture enforced within a project team
  • Ad hoc communication of architecture across project teams
  • Minimal improvements over Level 1
  • Some successful practices are repeatable
  • Recognition that an EA effort might be valuable
Level 3: Defined
  • An EA team is in place that defines a reference architecture and some software-development practices
  • Project teams are encouraged but not rewarded to use this architecture
  • EA does not meet all the needs of each LOB
  • Difficult to get consensus: EA teams and project teams don't work well together
  • Architecture maintenance is a big concern
  • Architecture has a shelf life of 6-12 months at most
Level 4: Managed
  • SOA is considered the end point for the architecture initiative
  • LOBs and EA teams work together to define an SOA
  • Support and governance models are in place
  • LOBs are rewarded to expose and consume services
  • Up-front costs seem to be prohibitive
  • Reduces risk of project delays resulting from inconsistencies in the architecture layer
  • SOA within the organization seems to get some momentum
Level 5: Optimizing
  • SOA becomes a starting point
  • Organizations want to explore service orientation with their customers, suppliers, and partners
  • Continuous architecture optimization
  • Business agility
  • Interoperates with services from customers, partners, suppliers, and others
  • Faster time-to-market
  • Lower Total Cost of Ownership (TCO)

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.

Other SOA / Web Services Maturity Models



Bookmark and Share
© 2016 Kunal Mittal All right reserved
Home | Startups | Publications | Blog | SOA | Cloud Computing | Web 2.0 | SaaS | Mobile | Resume | Contact