With a career stretching from corporate IT to working for pioneers, like Ivar Jacobson, I seem to have landed squarely in the field of Enterprise Architecture (EA). A practitioner for the past 10 years, I’ve become quite passionate about this profession. What peaks my interest is the changes occurring in the EA profession, accelerated by disruptive technologies and business transformation, and how companies realize the multitude of benefits EA offers.
I travel to London regularly and am very familiar with London’s underground railway system and its audible warning phrase “mind the gap”. This ear-splitting caution on the spatial gap between the train and platform struck me as a fitting expression of EA. Properly executed, EA bridges that gap between business and IT.
Having a strong EA function in place provides the information to make better-informed decisions. This article explores the benefits of applying focused Use Cases to help plan, communicate, and progress your EA objectives.
Like many, I’ve used EA Use Cases to show exactly what the technology can do for the “business” without using technical jargon ( a common complaint of business stakeholders). The Use Case is rapidly regaining popularity as a tool to capture the ways Business and IT stakeholders can interact and achieve specific goals by representing a collection of possible scenarios.
Application Portfolio Use Cases
Lets start with the application portfolio since a substantial percentage of IT funds are dedicated to it. Industry analysts predict “50-80% of IT spend is on licenses, support and maintenance functions. Not managing the application portfolio leads to increased complexity, reduced agility and exposure to a multiple risks such as, compliance, using old technology, and losing people with critical skills or application knowledge.
Typically the metadata about the application inventory, it’s associated technology, business value, cost and technical debt resides in spreadsheets, systems and in people’s memory banks and distributed across organizational silos. I am repeatedly surprised at the number of companies who lack an application inventory. Without this transparency it’s difficult to comprehend the relationships and interdependencies needed to analyze the data to make sound decisions.
So how do you write a Use Case?
The goal is develop a Use Case that captures “what” EA’s outcome does not “how” it does it. Use cases are business goals and great communication tools. The most common problem in creating a Use Case is either adding too much detail or not enough. If the Use Case doesn’t include enough detail, it’s going to resemble a process, and if it includes too much detail, it’s going to resemble a design document. Another misconception is that Use Cases must include complex visuals, such as UML activity diagrams. I find simple visualizations, such as nested cluster or landscape diagrams, compliment the Use Case making it easier for all stakeholders to understand.
EA Use Cases fall into four categories: Application Portfolio, Technology Portfolio, Business Capability and Investment, and Governance. The following EA cases provide high business value and help to bridge the gap between EA, IT and the Business.
| Name | Description |
| Inventory Management and Cost Analysis | Establish the inventory of applications to understand the portfolio; by descriptive information, ownership, and costs. |
| Business Alignment Analysis | Define applications in the context of how they are used by the enterprise; the business capabilities they support, organizations that use them, business locations where they are used, the business processes they automate. |
| Cost Analysis | Determine the Total Cost of Ownership (TCO) of an application. |
| Health and Risk Analysis | Discover the technology risk in the application portfolio by; extent to which the applications are deployed on aging or vulnerable software and hardware technologies. |
| Investment Analysis | Determine the cost of change, the impact of a change and the benefit of change to the business. Example: New project impact to the portfolio. |
| Rationalization Analysis | Determine rationalization disposition by determining elimination of redundancy and complexity; moving to the Cloud, and data center consolidation. |
Mergers and acquisitions typically drive a consolidation of applications. Most mergers begin with a consolidation and simplification of the application portfolio. This approach provides a fast payback time, allowing savings to be reinvested in further optimizations of the application portfolio.
| Use Case: MERGER – Application Consolidation | |
|
Scenario |
Establish an inventory of applications to understand the impact a corporate merger will have and to support a strategy for integrating the two corporations’ seamlessly. Includes descriptive information about each application; the ownership, the cost, the health and compliance levels. |
|
Triggering Event |
Company merger. |
|
Actors |
|
|
Audience |
|
|
Basic Flow |
Articulate the processes to configure a Landscape Diagram (report) and analyze the present and future proposed states of the applications.
|
|
Pre-Condition |
Using smartEA, populate the Application Building Blocks in order to create the visuals and run the report. Run a Visualization Diagram in the Application Building Block. Run a current state Landscape Diagram. Show future state by adding the following Application Building Block changes:
Population and Diagram instructions are provided in this link USE CASE MERGER – Application Inventory Management. |
Use Case Name – A clear description of the Use Case.
Scenario –– A very brief paragraph on the scope of the use case.
Triggering Event – the motivator or initiator of the Use Case.
Actors – A list of the types of users who engage in the Use Case activities.
Audience – the main people you want to reach and/ or could most benefit.
Basic Flow – A set of key steps the actors take to accomplish the goal of the Use Case.
Post Conditions – Anything that should be correct or true upon completing the Use Case.
