EA made EZer
Modeling tools can help agencies put their architectures in order
Enterprise architecture modeling is finally beginning to show some benefits for government agencies beyond mere compliance with the Clinger-Cohen Act.
As CIOs, other agency leaders and business analysts gain an increasingly accurate view of how their organizations and systems work, the information gathered in the modeling process is helping them make better and faster management decisions.
To get an idea of how that data is being applied, all you need to do is log into FEAMS—the Federal Enterprise Architecture Management System.
Maintained by the Federal Enterprise Architecture Program Management Office at the Office of Management and Budget, this Web tool lets federal users browse a unified Federal Enterprise Architecture Framework model. It shows agencies’ initiatives and business processes that other agencies might be able to link to or emulate.
Even within individual agencies, EA data is starting to pay off. According to Rick Thomas, Army Morale, Welfare and Recreation’s CIO, information within the Popkin Systems Architect repository helped determine that the requirements for a new business process—the Army’s world-class athlete program—could be handled by existing systems with little if any modification.
That kept the agency from wasting money and staff time developing new software—and the move wouldn’t have been obvious without the EA data.
But the model data isn’t yet as deep as Thomas would like it. He wants to use Popkin’s simulation capabilities to do what-if models of new processes. “For that simulation to work, you need a lot more data than just what’s in the architectural framework,” he said.
Eventually, architects and business analysts could even use models built with the same tools to drive the implementation of new processes—automatically generating everything down to the workflow code.
As modeling languages mature and become more standardized, a new class of software tools is emerging to let business analysts turn new process models into actual implementations based on existing software.
Getting a handle on what you have can be complicated. If your agency has been using model-driven development for applications and other elements of your technical architecture, collecting that data might be a little less strenuous.
Even if you’ve used previous generations of modeling tools to map out every process, business function and technical component of your agency, getting that model data to match up with the latest releases of the various components of the Federal Enterprise Architecture will depend on how well your tools can move data from their native format to Extensible Markup Language—and back.
The current de facto standard modeling language is UML, the Unified Modeling Language. UML has generally supplanted older modeling language standards, at least in the technical modeling world.
Now in version 1.5—with 2.0 nearing completion—UML is maintained by the Object Management Group and springs from the world of application and data object-oriented modeling tools. Because it comes from a software background, its business process modeling features are flavored with language from structured application development methodologies—capturing and tracing requirements, use-case models and so on. UML can take models all the way through the development of software objects.Filling the gaps
But new standards are seeking to take models the last mile. Over the past few years, a number of other business process description and modeling languages have emerged to fill in the gaps between modeling a process and actually deploying it. The latest contender is Business Process Execution Language for Web Services.
BPEL for Web Services isn’t a modeling language at all. It’s a flavor of XML used to create Web services or a service-oriented architecture.
Also known as BPEL4WS, it offers a way to take information from an EA model, with associated technical information, and convert it into a workflow or Web services implementation with little if any further software development.
BPEL4WS is used by application servers for what’s known as services orchestration—the rule set that governs the order in which certain parts of a workflow are done, and what information is passed from one step to the next.
Last year, IBM Corp. published a tool through its DeveloperWorks program that converts UML process models into BPEL for Web Services rule sets and the Web Services Definition Language interfaces that let developers and applications interact with the rule sets.
Middleware vendors such as Tibco Software Inc. are also working to build BPEL4WS into their software.
But BPEL is not something that government enterprise architects can simply pick up tomorrow—not exactly.
There are software systems that leverage BPEL today, but the modeling tools that help agencies comply with reporting requirements for the FEAF’s reference models don’t take the final step to automate creation of applications to support modeled processes.
Right now, the struggle is still focused on how to capture all of the data that makes up each of the components of the Federal EA model, and present it in a way that makes it useful to decision-makers, such as MWR’s Rick Thomas.
The government is by far the largest consumer of enterprise architecture tools and has an asymmetric impact on several of the leading EA tool vendors’ products.
Popkin’s System Architect, for example, has add-ins to help it directly leverage the FEAF. One add-in, Integrated Reference Model Architect, can import the current and future versions of reference models published by the OMB into the tool’s repository.
IRMA also provides a number of reports that can be integrated into Exhibit 300 submissions-showing how an organization’s business functions and how its proposed technology investments match up with the elements of the FEAF.
Computas’ Metis tool, an XML-based modeling system, also hooks into FEAF-because all of its data is stored in XML. Ira Grossman, chief architect of the National Oceanic and Atmospheric Administration, said groups can "go straight to OMB's FEA Project Management office, which has all the models in XML, and in less than a minute pull the suite of five reference models into Metis and link them to a bureau's architecture.”
“We pull the models straight out of OMB and then begin to create our own relationships and lines of sight on top of that,” he said.
For now, just getting the reports in is the most important part of what many agencies do with EA tools.
But that won’t last for long. As agencies start to find their way toward better-aligned enterprise architectures, and start to adopt service-oriented architectures and Web services to achieve them, the power of the tools they already have in hand will become too great to ignore. S. Michael Gallagher is an independent technology consultant and freelance writer in Maryland.
Connect with the GCN staff on Twitter @GCNtech.