SOA Blueprint: Frame by Frame

There’s a fascinating scene in the movie “Titanic” after the ship hits the iceberg: An engineer, studying the blueprints, announces that the ship is going down, and there’s nothing anyone can do about it.

At a conference a few years back, John Zachman, the father of enterprise architecture, explained why he loves that scene. The ship’s designers had created blueprints in such painstaking detail that, when disaster struck, the engineer could quickly determine how long they had before the ship would sink.

What’s more, any competent engineer could have looked at those same documents and come to the same conclusion. If the Titanic had had enough lifeboats, the engineer’s quick determination would have proved invaluable.

Such is the essence of enterprise architecture. In a nutshell, EA is a logical approach to blueprinting an enterprise so everyone understands the overarching organizational mission, lexicon and goals and can align information technology with those goals as efficiently as possible.

In the more than three decades since Zachman began promoting EA use, many government organizations are finally putting his framework to practical use.

If your IT infrastructure aligns with the business and you have kept a detailed and uniform understanding of the business in the form of blueprints, you can quickly, accurately and efficiently identify and react to change when it arises. Those blueprints will help you determine:

• changes needed for the new requirement;
• effect the changes will have on the organization;
• processes and applications available to meet the new requirement as quickly as possible.

Service-Oriented Architecture

These days, we keep hearing about the promise of service-oriented architecture and its ability to help IT organizations react to rapidly changing business needs. With SOA, you identify the services you need to achieve your mission and then try to find an existing reusable module that can do the job while sparing you a great deal of programming.

For instance, rather than having the Attorney General’s Office receive constant updates from the FBI and then store and process all that information in its own systems, the office can access updated information on an as-needed basis directly from the FBI’s system and do so for only those people they are interested in at that time. The office saves on hardware, development and maintenance costs by using an open standard to link to and use the FBI system.

The problem is that when you get into the details of executing SOA, many IT professionals struggle. They have a hard time wrapping their brains around the nuances and how to determine what the organization really needs.

Here’s a little secret: SOA isn’t new. It’s just a way of looking at long-standing ideas, such as EA, from a new perspective. The concept behind SOA is that you shouldn’t have to reinvent the wheel. As such, if you already blueprint your organization using Zachman’s EA framework, it makes sense to use that as your SOA foundation.

Before I go any further, it’s important to note that no one methodology is better than another. That is best decided by the IT maturity and needs of your agency.

In fact, organizations use a variety of architectural frameworks to model SOA, says Pradipa Karbhari, director of SOA and business integration for Capgemini’s Sogeti USA, an IT services provider with headquarters in Dayton, Ohio.

“Organizations need to follow architectural best practices to analyze their requirements, adopt multiple views or perspectives of the system and design their process flows and information flows, starting with a business-first approach,” Karbhari says.

As for me, I believe in keeping things simple. You can’t implement something if no one will understand it.

Engineering Your Ship

When I started at the New York State Office of the State Comptroller in 2003, I was the agency’s first CIO. Five IT shops had evolved through the years, each using its own systems, although the functions overlapped.

Take claims processing, for instance. Whether you’re handling a request for unclaimed funds or a disability benefit, the process is basically the same. It makes sense to reuse existing systems. But to start looking at system reuse this way, people must think of their unit in the context of the broader business entity.

I started by interviewing the agency’s senior business managers to learn about their goals and initiatives. I was then able to identify common needs so I could focus on IT projects that would be useful across the organization rather than just to single divisions.

That exercise established my initial five strategic priorities for IT at the Office of the State Comptroller: a secure Web portal for e-government, a data warehouse, a content management system, better remote connectivity and a security architecture.

These projects, which would serve the entire agency, helped demonstrate the Erector-set model of design — how reusable modules can build efficiencies. Instead of crafting a new beam or, in this case, a new database, you reuse what you already have in a new way.

You design it, build it, manage it, redesign it, rebuild it and so on. Eventually, you can get to market that much quicker because you’re not starting from scratch with each project but choosing from an inventory of reusable service modules that have been created over time.

Manageable Pieces

Zachman’s framework (see chart above) is a tool that can help you identify the reusable parts most critical to your organization. The framework analyzes the business by asking simple questions: what, how, where, who, when and why. People at different levels of the organization representing different points of view about the business and the technology must answer the questions.

For each process, all of the people on the chart must answer each question. Each process is represented as a horizontal sliver of information running across the chart. As more slivers fill each of the boxes, a more detailed picture of the enterprise emerges.

The first row represents the agency’s high-level Scope. In my case, it would be the comptroller’s vision for the agency — such as to improve operations by fostering innovation, making better use of technology, wisely aligning resources and employing a well-trained, diverse and professionally developed workforce.

Row 2 is the Business Model, in which the deputy comptrollers identify their goals for achieving the comptroller’s goals. For example, a deputy comptroller might wish to process paychecks 10 percent faster than last year.

The third row is the System Model. In the framework, the term “system” at this point has no relationship to IT, although IT might help in the planning. Using our paycheck example, the System Model would be how the deputy comptroller works with the payroll department to figure out a business strategy to process paychecks faster.

A key component in fully understanding the enterprise is to standardize naming conventions so that everyone knows what everyone else is talking about and trying to accomplish. Once a common lexicon is established and you go through each row and column of the Zachman framework, you start to create a unified vision for the agency and can identify common needs and initiatives.

It’s important to align business and IT to proceed with an SOA undertaking, Karbhari says. “The IT organization needs to understand the business goals of the entire organization and realign itself to prioritize the tasks it undertakes to line up with these goals.”

The SOA premise is that by understanding your department’s business processes, you can structure your IT environment so you can take standardized business process modules and loosely couple them to create many of the overall IT system components your group requires. That leaves you with a technical infrastructure that can address changing business needs quicker and more efficiently than before.

Once these modules exist, you can reuse them instead of creating them anew for each new requirement. In fact, you may not have to implement a new service but merely link to a location where it’s already running.

From a financial perspective, substantial returns can be realized through multiple instances of reuse, Karbhari says. “Return on investment arises from several factors, including the creation of dynamic, flexible, inexpensive, easily interchangeable systems with reduced development, integration, maintenance and support costs along with quicker time to market, increased revenue generation channels and improved risk profiles,” she says.

The individual process modules are known as services, and “architecture” means setting up your IT environment so that you can group multiple services. Consequently, such an IT environment is known as a service-oriented architecture.

Service Connection

Web services are often used to deploy SOA because, Karbhari says, they are loosely coupled architectures and have supporting standards to provide guidance, resources, best practices and promote interoperability across operating systems, technologies, languages and platforms.

But of course, just like enterprise architecture, making SOA work requires that you fully understand your business and describe it in a language that all users understand.

That’s the hard part. There are no shortcuts when it comes to EA or SOA. You’ve got to lock people in a room, hash things out and try to find common ground, and that takes a lot of time. Be prepared for resistance. People worried about their day-to-day functions aren’t usually anxious to sit in a room, talk about high-level concepts and make compromises based on the needs of other divisions. You might have to go slow before you reap the benefits.

When developing the State Comptroller’s secure portal, our EA exercise let us see that if left to their own devices, each division would have developed its own strategy for enrolling customers so that they could be issued passwords to use one of our secure portal applications. Instead, we brought all stakeholders together and asked them to come up with only three types of enrollment processes that could work for everyone — one each for constituent, vendor and government enrollees. Now that these three services have been developed they can be used by whoever needs them. This saves time on new development and bug fixes, as well as intrusion testing and ongoing support.

The biggest challenge is getting people to think beyond their own needs and missions and to look at the overall business goal. That takes strong support from the top. But the rewards can be invaluable.