In 2004, we developed an approach for business transformation. Our primary goal was to mature the investment through addressing transformation core architecture concepts. These concepts included 1) Paving cowpaths, 2) Improving bad data lifecycles, 3) Avoiding redundant buying, 4) Balancing compliance with aligning programs, 5) Aligning products and services directly to performance drivers, and 6) Addressing inefficiencies. Our Team at the time was under a Northrop-Grumman Contract at the Department of the Interior. Department of the Interior had multiple representatives across the CIO and Management and Budget office functions. Their roles had been guiding and approving the enhancements. There were three team members from Xentity, one from Phase One Consulting Group. Also, one from IBM. The project also included management oversight by Northrop-Grumman.
Methodology
The method we developed would provide a collaborative way to bring cross-functional business representation with the architecture analysts and consulting service to walk through major analysis steps:
- Initiating the project
- Scoping the segment
- Business analysis
- Technical analysis
- Author recommendation set as blueprint
- Incorporate into Enterprise Plan and Portfolio
We knew we wanted to use architecture techniques to help meet our business transformation objectives. However, we also wanted to assure architecture did not follow the path that has appeared for the last fifteen years.
The approach we developed would not and has not engaged executive interest. Likely given the time it takes to collect the information and map to taxonomies, the information would become stale.
The result we devised was the Methodology for Business Transformation version 1.0 as seen in the figure below.
Lessons Learned
We used our new method and applied it against four major mission area blueprints. Since this was a version 1.0, we ran into several major issues: Enterprise Governance, OMB Functions, Change Management, Performance, CIO Office, Scoring, Solution, Governance, Cost Benefit, and General. But the largest issues were not in the analysis, but the wrappers around the method. Below are summaries of the top four lessons of the over 100 improvements we identified.
#1 Lesson Learned – Tick, Tock, Tick, Tock
For large organizations ($100 million to $1 billion), we knew we wanted to take a segment approach to building out the information while moving through the phases of transformation. In our first draft of the resulting segment analysis method, the transformation phases resulted in starting with Phase 3. The clock would start ticking as soon as a team was formed, funding for the team was assigned, and the project was kicked off.
This was a major issue after the first four blueprints, as we missed the key executive steps for assigning a sponsorship concept. Meaning, the definition for success was in the eye of the executive. We skipped the critical step of defining the sponsor and their executive level needs.
#2 Provide Precedence-Based Guidance On How Far To Mature
We knew we didn’t want to re-invent how we develop service level maturity. So in 2005, as part of looking at our transformation approach, we examined the GAO INFORMATION TECHNOLOGY INVESTMENT MANAGEMENT, A Framework for Assessing and Improving Process Maturity – (ITIM) – detailing “Select, Control, Evaluate” phases of management, background on proposed processes to improve IT Investment Management.
And for guiding the maturity for the actual capabilities, we relied heavily on IT Infrastructure Library (ITIL v3) Management Best Practices (ITIL) to help in guiding how to move from reactive service to proactive and not reach to far while gaining improvements and efficiency
#3 Showing The Line Of Sight
We needed to clearly show how the analysis and resulting work supports business drivers, and the full business value chain.
Some Enterprise Architecture experts may argue the existing Frameworks, such as Zachman, accomplishes that, and it does in a library function. However, it does not in a journalistic function which tells it in story mode and pockets the products as due diligence.
#4 Change Is The Message, EA Is Just A Set Of Tools – Get Over Ourselves
This moved Enterprise Architecture (EA) out of focus and moved the mission of the segment analysis in its place. EA became a supporting role, and we would attempt to remove EA from the vernacular. The obvious reaction is this was done because of the brand beating it has taken since 1996 when the intentions of Clinger-Cohen reduced EA into an IT compliance reporting role. It was actually more so of EA`s own culture to put EA at the center of the universe when analyzing, ideating, managing change is at the center.
In our over 100 other improvements, other areas highlighted are:
|  |
What Results…
The result ended up not being a full major release, because we had yet to address cultural transformation issues. Also, we still had additional concepts to consider for linking other ways to path through the method more as an approach.
The supporting toolkit for MBT is a large difference maker from whitepaper procedures or sample templates.
(2008: Later note, the MBT 1.5 ended up becoming the core method and set of templates for the Federal Segment Architecture Methodology (FSAM) which continues in aspects as a basis to the Common Approach to Federal Enterprise Architecture).
Two team members from Phase One Consulting Group, one of which on the original MBT team, supported this effort.
MBT has since been validated by the following organizations:
