MVEA – 3 Case Studies, 5 Lessons

Last year (early 2019), I wrote a series of articles regarding the concept of MVEA (Minimum Viable Enterprise Architecture) based on more than a decade of consulting experience working with over two dozen organisations.

During this year, I was then asked implement a further three MVEA Repositories (up to Stage 3), two of which were from scratch. This validated that the concepts and value of the MVEA methodology were sound and that using the techniques could provide this value fast and at low cost to businesses. This article summarises the results and lessons learned.

Quick recap - I proposed four phases of EA activities that each provide just sufficient architectural and strategic direction to allow businesses to adapt and respond to needs (especially digital needs) and deliver projects (including using Agile Project methodologies). Each phase is fast in delivery, and each builds on the previous phase to deliver more value.

•  Stage 1 - MVEA provides us with core: what (applications) used by who (business units) changed how (projects) and why (strategy).
• Stage 2 – Digistising Architecture making it all accessible in an online repository, adding Business Capabilities to link it all together.
• Stage 3 – Foundational Architecture further improved by linking together, and adding Processes, Data Entities, Infrastructure and including assessments of Business Capability.
• Stage 4 – Integral Architecture where Architecture becomes pervasively integral to business change.

You can find out more at this website: intron.com.au/mvea or by clicking on the links above to find the LinkedIn articles.

“Make no little plans. They have no magic to stir men’s blood.”

Sir Hubert Wilkins - Australian Explorer and perhaps the first climatologist.

Case Study 1 – MVEA Stage 2

Three years ago, I was asked to help this small (but growing) company establish an architecture practice. Their projects were heading in different directions with various levels of design in place. We did a classic MVEA phase 1 architecture review, produced the first, high level road-map and embedded some basic design governance processes into their project process. That was just enough architecture to provide a baseline and a guide for the future.

They outgrew that and so the CTO invited me back to deliver the next phase and lift the architecture practice a little higher - to stage 2. Once again, a transformational project was kicking off and everyone knew that this significant technology enhancement needed careful design and planning.

Within two weeks the Architecture Repository (delivered as an Excel spreadsheet) had been re-awakened, reviewed and updated, and the resulting review highlighted just why system integration was going to be a key challenge. The issue was how to bring this to the attention of the executives with any real credibility. We also needed to drill deeper into the process and data architecture of the new core system being implemented and develop a mechanism to assess the design of interfaces.

Two weeks later the whole repository had been moved to a SharePoint Online implementation, giving access to all in the company. The solutions architects were initially skeptical, but once a project manager introduced it to his project team, it was not long before the team members were updating process and interface details directly. SharePoint made this collaboration simple and the result was profound, for example the impact of a change in process to an interface and therefore to another application, could be quickly and accurately assessed. In some cases, data was updated live and in real-time into the repository during workshops, meaning that the outputs of new models were produced immediately after the meeting, as the diagram only needed a refresh of data. The turn-around was so fast that coders sometimes were unprepared for the design documents. Accuracy was improved by an estimated 70%, while sprint schedules shifted gear as fixes were available sooner.

“You’ve done me out of my job”, said one seasoned project manager, who until then had been the font of all knowledge on a set of applications and interfaces.

From now on, guessing on the status of an application or its interface details no longer happened, instead, people were referring to the Architecture Repository on their phones to assess new design ideas or respond to questions in meetings. 

Applications names removed to protect sensitive information and the innocent.

The above diagram instigated a deeper dive and creation of a comprehensive integration strategy to tackle a growing problem. Just the visualization makes it clear to executives what is needed and going through this and the Architecture Repository, with its drill down capability, helped persuade the CFO about the necessity of investing in interoperability.

Lesson 1: Power to the people. Make the Architecture Repository available to the project delivery teams, they have less to lose and most to gain from the understanding and using the architecture and are the agents of change.

?Case Study 2 – MVEA to Global Technology Strategy - upper limits

Phonecall: “I’ve been quoted three quarters of a million dollars to deliver an IT strategy and target architecture in three months, what do you think?” said the CIO of a newly formed global organization. After explaining that I thought this was a fairly normal “top-down” approach to producing such a thing, usually offered by the big consultancies, I suggested there were other ways to achieve the same or achieve better results with less money.

“Could you do it using your MVEA method? A bottom-up approach? Say over six to eight months? The point is there are some obvious things we need to do and I don’t want to spend money and then wait to be told the obvious. I also need to involve the technical staff in each region,” the CIO asked.

I explained that I was already committed to another customer but that my team could work on this to an equivalent of 3-4 days per week. I said I thought we could produce a current state architecture in about three months, and then we would consult with the in-region staff before moving to a target architecture and then pull it all into a detailed strategy and road-map. We started the next week.

With offices spread from South America, through Europe and Asia to New Zealand, time zones were a problem as not everyone was awake at the same time, but they all provided application and server information and within two weeks we had the first business and applications models ready for review and validation. Our deadline was a workshop with all regional leaders where the current state architecture needed to be presented – detailing over 450 applications and almost 1000 servers in total.

Once the architecture principles were agreed for future decisions and the core applications (especially global ones) were defined and agreed, it was back to the Architecture Repository to create the target state.

We delivered a global Architecture Repository within the time frame that was globally accessible and featured every application and every server that existed. This can now be used as a reference to develop interfaces, process definitions and more detailed solutions for global and regional support.

The above road-map provides multiple views with unique insights into the evolved architecture

Being a large organization with many business areas, multiple geographies, regulatory requirements, languages and drivers, it was sometimes hard to know how to respond to the needs and provide an accurate picture that made sense of the diversity and complexity.

So, we went back to the basics of the MVEA. We delivered the core models that helped the executives understand their business and what needed to be done. We consolidated all eight regions and produced the same basic models for comparison, with slightly different views, and then one for the whole globe. We delivered a detailed technology strategy, road-map and target architecture at about one quarter of the original quoted cost. 

Lesson 2: Keep it simple. Bring it back to the simple. The MVEA method works for larger organisations too and can provide simplification and clarity when normally the sheer scale causes complexity and confusion. 

Case Study 3 – Twenty-five days - start to finish – the quickest yet

A medium sized government agency requested an architecture review and a three-year road-map. They already had a list of their applications in a suitable format with application assessments done, so we already had the core information required. We just followed the MVEA steps as folllows:

Step 1 Architecture Repository - Within 5 days we had setup their SharePoint Online Repository, loaded the data and had set up an organizational application model diagram and an application status model (sometime knows as a reference model) with applications categorized using the government standards as required. It really was that quick!

This provided some immediate insights of their application portfolio and allowed us to link to the government's strategic platforms. We could already see some of the more obvious issues and what needed to be done.

Step 2 Business Capability Model - Then followed a series of workshops with business representatives of each area to create a Business Capability model; over which the applications were laid. This overlay gave us a clear view of the impacts of various projects on the business, based on the applications they were changing.

Step 3 Pull it together into Road-map - The bulk of the work was done by day twenty, and once we had brought in their project plans we could create a road-map and align it to their business strategy to create a technology strategy based on the insights the models gave us. There were some standout elements of collaboration and knowledge management needs that weren’t being addressed consistently. It was just a matter of walking everyone through it, getting feedback and then finalizing the details with clear recommendations.

Because collaboration was an important element in this business, we did a (fast) deep dive into this area, showing how flexible the MVEA framework can be to drill into areas of specific concern. We created a lower level Business Capability map for Collaboration (as a capability on its own right). We then overlaid the System Capabilities that would support the business capabilities. Then on top of that, we laid the current and future applications that delivered those system capabilities, colour-coded to show their status. The result was a very interesting view that I suspect may resonate with many organisations today. The view shown below was after we had specified some of the road-map projects to implement a full Office 365 using SharePoint Online. So, this really is a current AND target view.

Lesson 3: Speed matters, but quality counts. The speed required was due to available budget but also to meet a specific deadline and this meant we had to de-scope some elements. However, we maintained depth on items that were important, so the value, credibility and applicability was retained. Don’t let speed cut off your last “Y”

There were two more lessons that appeared across these three implementations, these were:

Lesson 4: Use their help. People want to help and be a part of it even if they naturally tend to resist change. The majority of people I worked with over these three implementation (about sixty) wanted to support and help and were genuinely interested in the process. We found by handing it over to them, with the right direction, we got the greatest input and the best results.

Lesson 5: Link to the Business Strategy. It may seem obvious, but it is often neglected by tech. people. By spending some time linking the technology strategy to the business strategy and ensuring they were aligned, we got the business buy-in (from the 'C' level) we needed.

When the COO's of the above organisations demanded a poster-sized print out of the road-map for their office walls, we knew we had delivered value.