email article
	printer friendly

Model Strategy and Mission in UML Profiles
Empower executives to gain "line of sight" from business drivers to IT investment
by Rick Murphy

Posted March 25, 2004

To address the challenge of modeling strategy, mission, and business drivers in UML, enterprise architects extend the semantics of the Uniform Modeling Language (UML) reference metamodel by including concepts defined by C-level executives in planning documents. For example, an enterprise architect would model the Federal Enterprise Architecture (FEA) in UML with concepts derived from the FEA program management office's Service Component Reference Model (SRM) using stereotypes, tagged values, and constraints. By extending the semantics of the UML reference metamodel with business concepts from a problem domain, enterprise architects solve the central problem of enterprise architecture: aligning IT direction with business strategy.

In my article, "An SOA for the Federal Enterprise" (Enterprise Architect, Fall 2003), I modeled Simplified Delivery of Services to Citizens with a UML use case diagram and its implementation with a component diagram as a services-oriented architecture (SOA). Here, I generalize on this approach and describe how to define an extended UML profile that models federated, business, and distributed component abstractions from the SRM. I call this extended UML profile "Line of Sight" because I can see strategy and mission in my UML artifacts.

Achieving Line of Sight
In his keynote speech before an e-government conference last fall in Washington, DC, Norman Lorentz, outgoing chief architect of the Office of Management and Budget, identified line of sight as one of the key challenges for the FEA. Lorentz described line of sight as the ability for executives to see the significance and outcome of strategy, mission, and business drivers at all levels of the FEA.

The FEA program management office defines line of sight as "the indirect or direct cause-and-effect relationship from a specific IT investment to the processes it supports, and by extension the customers it serves and the mission-related outcomes it contributes to." Regardless of whether the framework is Zachman, FEAF, TOGAF, EAP, DODAF, or another, enterprise architects visualize the intent of an information technology investment in their artifacts.

This visualization is especially important where artifacts cross levels of abstraction. Enterprise architects empower executives to see through the levels and build credibility by modeling the intent of an information technology investment across all levels of abstraction. See Figure 1 for an example of what an enterprise architecture may look like to a C-level executive whose view is obscured across levels of abstraction in an enterprise architecture without line of sight.

Enterprise architectures that achieve line of sight with an extended UML profile transcend business process reengineering, budgetary, and project management approaches to business modernization. Enterprise architects differentiate their core competency as the ability to communicate with visual models across levels of abstraction to ensure the expected outcome of an information technology investment. To achieve line of sight in an enterprise architecture through UML, we must first embrace the promise of UML and its reference metamodel.

Enterprise Architecture and UML
Enterprise architecture is often characterized by modeling business concepts as geometric shapes without well-defined semantics. The outcome of an enterprise architecture engagement is typically a planning document that creates a shared understanding and references the underlying technologies through textual notation. Today, cross-functional design teams labor to achieve consensus and communicate their vision on each engagement and for each framework. Every box, square, triangle, and arrow in a diagram is hotly debated, which precisely describes the state of modeling software architecture before UML.

UML provides cross-functional design teams with a shared understanding through visual notation, methodology independence, well-defined semantics, and expressiveness across various levels of abstraction. UML tools provide a semantic backplane, a shared repository, interoperability through XMI, and round-trip engineering. By leveraging UML tools and designing toward the nonfunctional requirements of modularity, loose coupling, high cohesion, contracts, and pluggable behavior, enterprise architects create an actionable architecture at the lowest possible, long-term cost. What we must do is integrate strategy into UML models to achieve line of sight.

Of course, UML is not the only approach, but we haven't fully exploited its power. Exciting opportunities exist to model business processes through BPML, BPMN, BPEL4WS, and others, but those standards imply process change. I recently led an enterprise architecture engagement where we chose to avoid process change and focus on artifacts. This approach reduced complexity and accelerated the approval process.