SOA starts at the top

When government information technology managers approach service-oriented architectures, they have a tendency to focus on two issues: the technology they think they need, and the budget required to move the project along. However, as we learn more about SOA, we discover that neither of those issues are directly linked to the success of the project, or the architecture, holistically. Thus, perhaps anyone attempting to build SOA in the government needs to focus more on the fundamentals, including driving change from the top.

In a recent Burton Group Study, researchers discovered that organizations that are successful with SOA focused more on the people and processes, as well as the value that leadership placed on SOA. Indeed, many organizations were able to succeed with SOA through a leadership change, which drove a culture change, and thus the ability to place more strategic value around a systemic change in IT, which SOA brings. In essence, the ability to change IT around the framework of SOA was functionally dependent on the ability of leadership to adopt, well, the notion of change.

SOA requires an acceptance that the IT architecture needs to change in order to create an architecture that has the agility to support change. This requires, in many cases, that the existing architecture be broken down to a functional primitive, understood and defined, then built up again leveraging the notion of SOA as a guiding framework. The end result is an IT infrastructure that’s very adaptable to mission and business changes. And the ability to adjust quickly to mission changes is a primary value point for the government.

In the government, the stakeholders are relatively apparent, but the real value of this process is to locate those who both control the budget and have a vested interest in the project/contract. These people are not always the obvious players, and you should take care to define not only the business objectives of the project, but the vision of each of the stakeholders. You’ll find many good ideas exist here, and the people with those ideas will, in turn, have a vested interest in moving the new architecture forward.

In moving toward SOA, you need to first do some homework, including creating a semantic or data-level understanding of problem domain, a service-level understanding of the problem domain, and finally a process-level understanding of the problem domain. We do this to define the “as is” state of the architecture, or what resources currently exist. You’ll find that these resources make up 80 percent to 90 percent of your SOA, albeit abstracted differently to support the architecture.

Data understanding is what it sounds like -- understanding the metadata native to all source and target systems within the problem domain. This means who owns it, its physical structure and how you would like the information re-represented to better support the business. You go through the same process with the candidate services that you have within the existing systems -- typically not Web services, but functions that have the potential to become services that work within the SOA. Finally, we need to define which information is attached to which services, and how those services exist in the context of the existing processes, automated or not.

Once we understand the “as-is” state, we need to define the details around our SOA, which is SOA in the narrow, or “to be.” In essence, we take our current resources as defined previously and place them in a new configuration, with some new technology and some new approaches, including SOA governance, data abstraction, service development and so forth. Those approaches derive new value from the existing systems, with the end game being the abstraction of all relevant services, with information bound to those services, into a configurable domain that creates and recreates core business solutions at will.

As you can see from the work that must be done, SOA is systemic to all relevant information systems in the domain, perhaps the enterprise or agency. Thus, there are many people who come into play as well, and they must be incorporated into the process of building a SOA. SOAs are scary things for the government in that they drive changes to many systems that have been undisturbed for years, and to many people and organizations have ownership of those systems.

Thus, make sure you do the following:

• Over-communicate with the stakeholders, starting from the top of the organization and working down. Make sure to define the value up front, and make commitments you can live up to.
• Define a clear plan, and make sure to incorporate all of the players in the development of that plan so there is clear buy-in, high and low in the organization.
• Define your SOA around short tactical wins that bring success quickly. In essence, define your SOA around many small successes, not one big one.