How Zachman’s enterprise architecture framework can help agencies approach SOA and stay afloat now that they run in “Internet time.”
“I believe in keeping things simple. You can’t implement something if no one will understand it,” Jeffrey S. Grunfeld, CIO, New York State Office of the State Comptroller.
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:
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.
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.
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.
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.
The typical relationship between government and information technology is rarely proactive. Traditionally, when a department needs a technology, the manager goes to the IT team and explains what he needs. The project is then added to the to-do list and implemented when time and resources allow. That could be the next day, the next month or the next year.
When IT was used only as a tool for accounting and other back-office functions, this approach worked OK. But as government grows increasingly dependent on IT for front-end, Internet-driven services, this scenario becomes less and less acceptable. When you’re operating on Internet time, a process built around IT prioritizing its projects and then developing an application that will meet the needs of only one department is too slow and inefficient.
In a carefully blueprinted enterprise, on the other hand, the agency has painstakingly documented its needs. With a bird’s-eye view of the organization, workers can proactively identify potential problems and adapt quickly to change instead of churning along as a series of reactive unconnected parts, each operating independently.
If a department in a well-engineered organization needs a new tool, IT doesn’t need to invent it from scratch. It can look across the enterprise to see if it already has such a tool. Or it can determine which departments need similar tools and work to devise an approach that can solve several problems, rather than just one. Service-oriented architecture takes this concept a step further by looking outside the organization — to a partner, colleague or vendor — to find those tools.
How does one go about blueprinting an organization? John Zachman first started developing the concept of enterprise architecture in 1970 while working at IBM. But his framework, developed in 1987, only became popular when the federal government passed the Clinger-Cohen Act of 1996. The law requires that all IT initiatives be directly tied to specific business needs, and EA is a way to accomplish that requirement.
Instead of looking at business requirements one request at a time and then building a specific system to address those requirements, Zachman’s framework seeks to analyze and document, or blueprint, the business from the top down and then use that knowledge to tailor an IT infrastructure that can best address an organization’s needs as a whole.
SOA is similar to EA in that both incorporate system models added to address new business requirements as quickly as possible. Instead of people from just one organization working together to achieve enterprise goals, people from different organizations can work together to achieve their mutual goals.
If you’ve crafted an EA, or blueprint of your agency, it will help you determine: