Introduction and Background
Condensed versions of this methodology can be found on the following linkedin article:
And an endorsement from Nicki Doble, Goup CIO of Cover More
Imagine if, when you bought your house, they gave you your own (secured) website that held every bit of information about it. You could see all the elevations and know the exact sizes of every room.
Every electrical cable and socket and switch is shown, all the plumbing too. All the appliances were listed with model numbers and maintenance schedules and instructions. Even changes or renovations that were made had been updated. From this information you could predict when your light globes would expire, when your air-conditioning needed servicing.
You could provide access to your tradesmen so they had all the measurements and could quickly provide you with an accurate quote without even visiting the house. The plumber would know the taps or where the guttering flows, and the electrician would know the lengths of cable they would need to put in a new power point. And if you were planning an extension the architect could very quickly come up with some options and costs by looking at the plans. He could even model the new extension, so you could see what it might look like.
We could call that a building architecture repository. It can also be called a Digital Twin.
Now imagine you had the same kind of database for your business, all the components catalogued as well as all the relationships between the components. You would store all the people, processes, technology and information that is involved in your business – these are the elements that make up Business Capabilities. You would include all the buildings and assets the business owned. Their make, vendor and their life-cycle status, meaning how old they were and therefore when you plan (if ever) to replace them. You would also ensure you recorded how they linked to each other and all the projects you have running or plan to run that would be improving or replacing or in some way impacting these components. You might even asses them in terms of their maturity (MMI) or generally how good they were at doing their job (whether you liked them) and those assessments might affect your plans. Then you would use this information to influence how you spent your money, and because you would need to persuade the executives and the board you would produce reports dashboards and diagrams that describe all this information. This you would call your design, your current design and the target design of where it will be after you have spent your money. This we call Enterprise Architecture. And the database that holds all this information is often called an Architecture Repository. Again – this is a Digital Twin of your business.
It’s a good idea isn’t it? Surprisingly I have found very few organisations actually do this in one place. I have been a consultant Enterprise Architect for the last 10 years working mostly in Sydney and have worked for over two dozen companies including large iconic financial institutions, construction companies, utility companies and a few government agencies and very few actually have all this information readily available, and certainly not in one place. In some cases, it exists in pockets – like part of a project, or one division. In many cases technology assets may be recorded in an operational system, but that’s in order to manage the systems, or some spreadsheets might hold some of it. I know this because for many I have built such systems either using expensive tools or just making do with the basics – and Excel spreadsheet.
The reason that these don’t exist is that they are generally expensive to create from scratch, and also expensive to maintain.
So, I have created a free Architecture Repository that you can use as an example of a proof of concept. It is enough to allow you to do what I call, Minimum Viable Enterprise Architecture (MVEA). It’s something that can help demonstrate how valuable something like this could be, and how it could work. It contains actual data in it about a made-up company. It’s free because this is not very clever in itself and I know many people and organisations have built something similar. If that is not the case in your organization, then you can take this free version and replace the “example” data with your own – it wouldn’t take long. You can then analyse your data and demonstrate the potential value of doing this properly. However, the free version has some limitations of course. It’s much like any other tool that sits on its own and needs to be updated as an extra task. Maintenance becomes an issues.
If you are interested in getting a copy of the working MVEA-R just email firstname.lastname@example.org.
I have then defined three further stages of such an Architecture Repository that you can build yourself from the free MVEA version to get more useful information and sophisticated outputs, but to maintain it you require better collaboration tools and so I have used Sharepoint Online as my example of this (although there are other tools). The trick is to use the collaboration tool as you work, so that it automatically updates the repository. In other words, as part of a project, a business analyst, architect, designer or delivery person, even the project manager, would use the tools linked directly to the repository so that all work was reflected back into the database as they work. It becomes just the way you work. Everyone becomes an architect and you do it as you work.
Below are the 4 stages – Scroll down to see each stage
- Stage 1 Minimum Viable Enterprise Architecture
- Stage 2 Digitised Architecture
- Stage 3 Foundational Architecture
- Stage 4 Integral Architecture
But first let’s look at stage one – the MVEA. (Section below was posted in Linkedin in January 2018)
Stage 1: Minimum Viable Enterprise Architecture
It is not only in-vogue and fashionable to be lean and apply the techniques of AGILE to everything we do, it’s also quite useful and often a necessity. For the last ten years I have been providing consultancy services through Intron Pty Limited to a wide range of large businesses and organisations, from the big Financial Services to Utilities and Government.
However, I’ve also had opportunities to work with medium-sized organisations who find it hard to be able to afford dedicated, full-time and (often) overpriced consultants or staff to develop their Enterprise Architecture capability. Often there are competing demands between the PMO and Architecture team resulting in the delivery team seeing architecture as a “tax” they must pay in order to get through the stages imposed by some out-of-tune executive committee.
Fortunately, there are many CIO’s and senior executives that continue to see the value of Enterprise Architecture and its ability to develop short-term and big picture views of their technology investment. They feel a certain dependency on architecture as its trusted advisor for their long-term plans, application and technology roadmaps and ultimately well-informed investment decisions.
Leaders of technical teams and business solutions also see the need for strategic direction, high level target state architectures and logical building blocks from which can set the direction and reduce “re-invention of wheels”.
Whilst the need is apparent, the willingness to invest in a proper architecture capability is driven through a financial lens which demands a strong business case and ROI.
Needless to say, one struggles to find any mature architecture capability these days which is why over the last few years I have increasingly been asked to provide just enough, or lean/agile Enterprise Architecture with whatever tools are available.
The prevailing request is: “What can you do for me that is EA, that doesn’t cost me a fortune, but helps me deliver my projects as well as ensure they are strategically aligned.”
My answer is what I call MVEA – Minimal Viable Enterprise Architecture.
A simple definition of “Viable” is “capable of working successfully”, and so what we are looking for is some EA that simply works – but what is that?
Well, this could be a long debate and just a simple internet search will deliver a seemingly endless list of definitions, descriptions and diatribes on what EA is, isn’t, should be and could be. For the purpose of this article therefore, I’m going to suggest only two “customers” and concentrate on what it is they most need from EA.
Customer 1 – An Executive Committee (or somebody that has the power to make decisions about capital spend of projects)
Needs: An indication of the future impacts of the capital they are spending in their organisation, and particularly a view on what they are not addressing. Or more simply, are they making the right decisions?
Customer 2 – A Project Team (preferably a largish, transformation project or program).
Needs: Confirmation (or not) that their project, especially the spend on technology is adequate and furthermore, some direction that their solution is one that fits in with the organization’s long term strategic plans.
Now, I know there could (and should) be much more value that EA can provide to an organisation and that EA is not only about technology and it should be more holistic. But the reality is that even nowadays the EA activity is often owned by, and very much pointed at technology and that mostly everyone just wants agreement that they are making wise technology decisions. This is about minimum and viable, not desired, desirable, wishful or the way the world should be. Furthermore, the idea is to start with MVEA and progress to a fuller EA in later stages.
You got to start somewhere.
Five Steps to MVEA
If we can agree that MVEA must fulfill the above needs for the above two customers, then what I have found is the most useful, valuable and effective recipe is as follows:
The concept is to reuse as much of the information that is available – therefore, a current Org. chart from the HR department, a list of Apps from the CMDB and a list of projects from the PMO. Combining this information is where the value is.
- Take your current Organisational chart
- Org, charts are often about people, but if you can convert this to departments and teams the you can very quickly create a functional model. In many cases the Org. chart actually is a rough functional model of your organisation.
- Add an Application Portfolio – basically a list of all your applications (perhaps a dump from a CMDB?)
- You may need to limit this only to the CRITICAL, or the CORE (I.E. applications that are used for the primary business functions)
- If you can, do a quick assessment of each application as to its technical status – just a Good, Average, Poor score will do.
- If you can, also show the interfaces between the applications – not in great detail, but just indicate whether applications are dependant on each other for data.
- Then link your Organisational/functional Units to the Applications in terms of what they use as the core of their business
- You can do this in a spreadsheet and then visualise by drawing boxes on top of boxes, or whatever way is the most visually impactful
- Next, get a list of your projects and link them to the applications they will change or impact
- Include new applications and old applications you are shutting down too
- Mark the status of the application based on this impact: is it being invested in, just in maintenance mode, or being retired or is it a new?
- Finally, get the business to provide the Business Strategy or whatever document from which you can extract their vision, mission, goals, drivers, measures.
- Link these to your projects too, so we know which projects are aligned with what part of the business strategy
So you are aiming at this:
Which all can be achieved using standard Microsoft Office tools– e.g. using Visio to provide the visualization of the data where the shapes ares data-linked to an Excel Spreadsheet, in this way heat mapping can become automatic and quick to perform or update. Similar effects can be achieved using Google Sheets and Lucid Charts in which changes in the underlying data will automatically be reflected in the visualization. For example, changing the status of an application will change its colour in the diagram. This is important and powerful as it allows you to change the data and quickly view the result, in some case almost interactively.
The objective of going to all this trouble is to be able to gain some insights and provide evidence into the state of the technology from the data you have, both current and future and as always, the more information you have got the better your insights, but equally, the more data you have, the more you want.
For example, if you have a list of applications it’s useful to categorise them in terms of their capabilities or services they provide – this helps designers understand that many applications have a wide range of features and functions that could be re-used. If you do manage to do a technical assessment of the applications, it is often useful to also do a functional assessment. You also might like to categorise the applications that are SaaS or cloud based and those that are not. All these extra bits of data enrich the insights you can provide to your customers.
Very briefly, here are a small set of examples of the most useful insights that can easily be drawn from this rather limited minimum repository. These have been created using simple Excel and a few pivot tables.
Of course, with more time (and more data) you can produce more, and using tools like PowerBI can include interactive drill downs and filtering. It also depends on the needs of the project, what they are trying to achieve.
One very useful summary is to bring the project information together with the above insights and artifact into a road-map, showing a current state and a target state all in one page. Like this MVEA example below:
So, there you have the MVEA Repository. Essentially an application portfolio linked to business functions and initiatives. This is providing evidence-based clarity to executives in a holistic manner, and for the projects they have a sense of where their project sits in the Enterprise, its importance and value and whether the new applications they are bringing in or updating is adding value and aligned with an overall strategy … or not. The insights should spark some questions at the very least to validate assumptions.
Depending on the amount of information already available from CMDB’s or various spreadsheets, this level of insights can be obtained within just a couple of weeks, and then maintained every time any project touches any of these areas, by simply updating the data in a spreadsheet. Subject matter experts can be asked to update their applications or projects as they go. The data can accumulate and be enriched every time an MVEA is performed for a project. Remember, it does not have to be fully accurate – just enough and just in time.
But this is just a first stage, the next stage of maturity builds on this base, adding incrementally to the data and capability and moving away from the basic tools, using the power of collaboration such as MS Office 365 and SharePoint. This delivers the next value from MVEA to Digitise EA (stage 2) and beyond, with architecture out there, always available to everyone and interactive…. coming soon.
A working example of this MVEA-R approach is available for free-of-charge on request. Consisting of a MS Excel spreadsheet and a few Visio diagrams. It shows what can be done as a proof of concept and then how to add to it to grow the value and maturity in four stages.
If you are interested in the MVEA-R example please visit our Contacts Page and fill in an inquiry form or email us directly an email@example.com.
Stage 2: Digitise your Enterprise Architecture
Once you have complete an MVEA stage (Minimum Viable Enterprise Architecture) it is very tempting to just keep on going and add more data and more artifacts using the simple tools you have, but this temptation must be resisted. The MVEA-R (Repository) is minimal and while it’s possible to do more with it, one must remember that it’s a very clunky tool to use. It’s not multi-user, its time intensive and each item added increases the complexity and maintenance required. Believe me I have tried.
However, we can use the MVEA-R model to get Stage 2 going and this is what I have done for the purpose of this example. The MVEA-R Architecture Inventory excel spreadsheet includes a number of extra Tabs (some empty) these can be used to collect data in preparation for migration to a digital Architecture Repository.
(More details about MVEA can be found here: intron.com.au/mvea)
Four Steps to Stage 2
- Introduce a multi-user, interactive and collaborative repository using SharePoint Online (or something similar)
- Implement a website with a direct link to the Architecture folder structure – uploaded from the MVEA-R structure and incorporating document management features such as versioning.
- Upload your MVEA-R catalogues (especially Application) from your Architecture Inventory Spreadsheet into SharePoint lists
- Relink your Visio models to the SharePoint lists, add in a hyperlink from each shape so you can open and edit the SharePoint list records with just one click.
- Introduce a Business Capability Model
- This will replace the Organisational model we used to model the business.
- Create a catalogue of Business Capabilities as a SharePoint List.
- Create a Visio diagram linked to the Capability Catalogue
- Link Applications to Business Capabilities
- Another mapping exercise like we did in the MVEA, but this time it’s application to business capability.
- The previous work mapping the org units (don’t throw it away) helps us here.
- Develop a Technology Catalogue (I.E. non-Applications)
- Expand our level of technology catalogue to include non-applications.
- Add to or create a new Catalogue (SharePoint List) of all your technology items such as hardware, operating systems and tools.
- Assess the Technical Status of these items (this will define our technology standards)
- Introduce a Integration Architecture Model
- Create a catalogue of each interface (including manual ones) – as a SharePoint List of course.
- This will give a you a good idea of your integration needs.
Stage 2 looks something like this:
We say “something like” because we need to be flexible and practical, we need to respond to the business’s needs.
For example, I helped a small company that had created over 200 websites spread over 10 providers and at any one time only 70% were actually accessible by customers. So we catalogued the websites, produced some stats. and came up with a plan where the priority was consolidation of websites and providers. In another company the issue was remote working for employees, and in a third it was storage. Be ready to adapt.
The suggestions here are only what seems to be common requirements.
Step 1 – Using SharePoint Online as a multi-user, interactive and collaborative repository
The greatest impact of this stage is actually this step – even if you don’t achieve the other sections below you will still get a huge benefit from moving the MVEA to the digital world as this will be the launch pad of Digitised Architecture.
This is how you get the architecture of your business in front of people. To make it accessible, consumable, relevant (timely) and real (valuable).
I’m using SharePoint Online as the example here because it’s very easy to move from the MVEA and re-use Visio shapes linked to SharePoint Lists instead of Excel Spreadsheets. After a bit of experimentation I believe that similar outcomes and value could be obtained using Google Sites, Google Sheets and other visualization tools such as Lucid charts.
There are four main steps to digitising your Architecture function:
1.1 – Creating the SharePoint Website and folder structure
This is not a tutorial on how to setup a SharePoint Online Website, so I am going to assume you have one setup and that you have administrator access.
Firstly, you can immediately load your MVEA folder structure into it including all diagrams. SharePoint makes this easy by allowing you to upload a folder including files, one at a time, so your Document Library should look something like this:
Secondly you can use all the power of SharePoint websites to make it look good and set up your Home Page so it links to the Architecture folder (note TAB next to “Home”). Later you can add much more such as FAQs, Glossaries, Architecture events (such as governance meetings or workshops and so on) and integrate with other Microsoft tools such as Teams for powerful collaboration. But right now we just need good content.
1.2 –Loading the MVEA data from the Architecture Inventory spreadsheet into the SharePoint Lists
While it is possible to load the Architecture Inventory Excel Spreadsheet directly, albeit sheet by sheet (you have to use Internet Explorer that supports ActiveX controls), I find it best to create the fields by hand and then copy and paste the data from the spreadsheet. It took me under 20 minutes to re-create the MVEA Application catalogue as a SharePoint List from scratch – so its not a huge task.
I can provide a detailed description of how to do this as there are a few little tricks, for example adding all the choices for the drop-downs (available in the Inventory Spreadsheet) and we need to create a field to store the URL for the List record so that it available as a hypertext link from Visio. (See the intron.com.au/mvea website and register your interest to get more information.)
For the diagrams to work on the SharePoint Online site we need to load the Applications, the Projects and the Org Units catalogue as a minimum.
1.3 – Linking the shapes in the various Model to the SharePoint list records
The Visio models have already been loaded into the document repository, so just a re-linking of the shapes to the SharePoint lists is now very easy. Visio is already setup for this:
1.4 – Getting everyone to use it
Just making these catalogues available can immediately be a benefit as anyone with access can now search these catalogues and immediately update and correct them. You can also send someone a link to the Application Catalogue and ask a Subject Matter Expert to update the record you have about the application they maybe an expert in. With versioning turned on all changes are logged in any case so little damage can be done.
I have found project teams often jump at the chance to use a database such as this, (rather than a spreadsheet) that is multi-user and can be used to report on the status of applications for their project. It’s easy to add fields for them and restrict views so they can add rich information to your database easily and cheaply.
The trick is to use the collaboration tools as you work, so that it automatically updates the repository. It’s no good making updating the repository an extra task. In other words, as part of a project, a business analyst, architect, designer or delivery person, would use the repository directly so that all work was reflected back into the database as they worked. It becomes just a new way you work. Everyone becomes an architect.
Another important tool available immediately is Power BI to replace the clunky Excel pivot tables with some powerful reports.
Visual Interface: Once the Visio models are available in the document library they can be searched for and used by anyone (with access to the website) with the help of Visio online (so no need for the full Visio) and the users can interact directly with the data in the backend database – online and in real-time.
Here is an example of using Visio online:
Notice that the Application information is shown on the right as users click on each Application Shape, and that there are 2 hyperlinks available. The “Edit Link” URL will open up the Application Catalogue (SharePoint List) directly at that record and allow the user to view or edit the underlying data in seconds.
Step 2: Introduce Business Capability Modelling
For a more detailed description of creating Business Capability Model see here (BCM: What,why how) This describes in greater detail what, why and how we create and use Business Capability modelling. For this article we only have this summary:
Business Capability Models provide a canvas on top of which we can visualise the real things – people (roles), processes, technology, and information (data) – that makeup that capability, allowing us to show business needs, dependencies and impacts of change in a way that helps decision makers.
Linking Applications to Business Capabilities
One of the first things we can do now is to link the applications we have to the Business Capabilities. We already have them linked to organisational units, so it’s just a short step to link them to Business Capabilities. Initially just doing it at a high level (level 1) is good enough. For example, it will show immediately any capabilities that are not serviced by an application.
You do this simply by taking your Business Capability model Visio diagram and overlaying the applications on top of the capabilities they are linked with, (colour coded as per the MVEA organizational model). Miraculously, you have shown the gaps which could be vulnerabilities (or not) of the business.
Here is an example of a Business Capability Model linked to supporting applications from the MVEA made-up company :
Once again – like the MVEA, the shapes shown above are directly linked to a SharePoint list Applications Catalogue.
Drawing insights from a BCM with an overlay depends on what appears. That’s the point of a model. It may not show anything more than you already know, or it may teach you something new.
In the above example some insights jump out (just a few mentioned here):
- One’s eye is drawn by the red highlight applications that are being retired, the Intranet and Exchange server.
- Asset & Risk Management & Strategic Business Planning are only supported by spreadsheets, but only Assets is due to be retired.
- Office 365 supports a wide set of core business capabilities, so is a critical application.
Step 3 – Creating a Technology Status Model
Having got ourselves a good list of the applications in the MVEA stage we need to expand on this and broaden our technology catalogue. In smaller organisations we can simply add a few fields to the Applications Catalogue to allow us to classify what are applications, and are what are databases etc. In larger organisations it might be worthwhile to split this out into it’s own technology catalogue.
The MVEA package includes a fairly simple categorization that works well and is practical, or you could go for a more extensive reference model such as the AGIMO TRM. If you want to get fancy you could even use the TBM classification which takes you to yet another level.
An important field here is the Standards Status (or similar description). This allows you to define whether this technology is a current standard or not. Immediately you can then provide a direction for architects and delivery teams, because, for example you could determine that Windows O/S 2008 is being retired, 2012 is standard and 2016 is under evaluation. It makes it very clear. It also is easy to determine as its not a matter of subjective choice, it’s about what is actually out there.
Insights: Run a report and count up the number of out-of-date operating systems you have, or the number of variations you have of different technologies, it can be very enlightening.
Visualising this with a diagram which shows the classifications and overlays the technologies (again colour coded) can make a compelling argument to do some de-duplication or upgrades – particularly if you can show these are not being addressed in the current project list.
Here is an example from the made-up company Widgets Pty Ltd (from the MVEA model):
You’re now adding value to the discussion on what the organization should spend their money on and with some real evidence about the state of the technology.
Step 4 – Producing an Integration Model
Everyone always seems very interested in integration. It’s often more expensive than anyone expects and when it goes wrong it gets more expensive. It is also an area that I have seen every single organization I’ve worked in (some two dozen), grapple with in some way or another.
Getting a good picture of what you have has the be the first step towards formulating a plan for the future and therefore an interface catalogue seems obvious. From this raw data one can create a visualisation that provide a model such as the one below:
The key to this step is to use the latest collaboration tools to publish and work with the minimum architecture you have already created. To make it accessible at any time by anyone; easy, cheap, intuitive and transparent, so that people (all people) want to use it to discover and correct the data. Project teams are usually the most useful here because they are changing the architecture and a tool like this helps capture that change. But also introducing Business Capability models and Technology Status models adds value and sets you up for the next stage where all this data can be brought together in a powerful Architecture Repository.
MVEA Stage 3 – Foundational Architecture
As a recap and preparation for Stage 3 we would have already built:
- Stage 1 MVEA (Minimum Viable Enterprise Architecture) which at the very least would provide us with an Application Catalogue, linked to the business units that use them, and linked to the projects that change them, and driven by the business strategy. In other words the what (applications) are used by the who (business units) that are both changed by the how (projects) and because of the why (strategy)
- Stage 2 – Digistising Architecture – all this information was placed in an easily accessible and usable online repository (using SharePoint as an example) and we added in business capabilities, some more technology information and further application interface information.
You can find out more about MVEA stage 1 and 2 at this website: intron.com.au/mvea or by clicking on the links above to the LinkedIn articles.
Stage 3 is called Foundational because this is the point at which EA moves from supporting business decisions and providing analysis and guidance to those decisions, into influencing strategic business direction and driving decision making. Prior to this the investment has been minimal, and while the value is not minimal, it is limited or restricted in scope. This next phase requires a little more investment but delivers much more value as a result.
Four Steps to Stage 3
- Link Capabilities to Process and Data Entities Catalogues (capabilities are already linked to Applications)
- Link Data Entities to Interfaces to enrich your interface knowledge
- Assess Processes, Data Entities & Technology to combined into an overall Capability score
- Add a Server Catalogue linked to Locations to develop a Geographic model and inform your application technology assessment.
It looks something like this:
NOTE: While its almost possible to do Stage 3 using SharePoint Lists, in reality this is not practicable. To implement Stage 3 you really need a more sophisticated tool (with a Relational Database) that allows you to link the data elements effectively, accurately and flexibly. There are a number on the market that can support this requirement.
Step 1 – Capabilities linked to Process and Data Catalogues
In stage 2 we introduced the concept of Business Capabilities as a relatively abstract way of modelling your business such that we can break those capabilities down into parts (Roles, Processes, Technology & Data) and therefore assess and focus on each of these. We also linked the technology that supported them (specifically Applications) to these Capabilities. Initially this was just by overlaying them on a Visio diagram but this linkage must now be held in the database so it can be reported on and managed.
Now it’s also time to link in high level processes and data to your capability model (Stage 4 brings in roles and another level of pain and complexity).
Processes will exist within Business Capabilities as a sequence of actions and decisions that support that capability. The best pace to start (if your company does not have all its processes already defined) would be APCQ. They provide a generic Cross Industry PCF ( Process Classification Framework) for free, or they also provide industry-specific PCFs as well so you can more closely match your business.
The APCQ level 1 Categories can easily be matched to your level 1 Business Capabilities, so use level 2 or below for this exercise. You may still find that some processes cover two or more capabilities, in which case duplicate them on the diagram, and ensure the links exist in your database model.
If you are trying to use SharePoint lists this linking can be managed by using the “Lookup” field type.
Here is an example of a Process Overlay (just using APCQ level 1) onto the BCM or our example Widgets company:
Going down to the next layer of business capability adds a huge amount of value of course, but also more work and analysis, however once done it changes very little. The above example is just to show it can be done and sits at level 1 for ease of explanation and display for this article, normally you would map to level 2 at least.
As for Data Entities, these just are names for groupings of data fields. Customer Order, for example would contain quite a few data fields, but would probably not contain Customer Information. At this point we are not going to detail all the data fields, just pick a name that adequately describes the fields and link them to the application where the data is mastered (if possible).
Once again a visualisation of the model that includes just data entities- in this case the data entities are just shown as hierarchy numbers so they can be included in the limited real estate of the diagrams, we are mostly interested in the score anyway. However if implemented in the Repository the specific data about the data entities can be drilled into.
The high level Data Entity catalogues looks like this for our example Widgets company.
Step 2 – Assessment of process, data & technology and capability
It’s now valuable, and possibly necessary, to begin to survey the business to create some assessments of these elements. Some people suggest CMMI as an excellent way to assess these components and then combine them (by averaging) to come up with an overall capability maturity. It all sounds good and scientific, but in practice I have found it overly complex and you end up fudging the numbers to suit your purpose. I recommend the simplicity of “Good, Average and Poor” for the individual elements and then combine them to include a Very Good (if all Good) and Very Poor (if all Poor). This will leave most assessments with an average score which to be honest is fairly normal and you can show above and below average as well. The objective here is to ensure that when visualised on a heat-map the very poor and the poor stand out with unequivocal obviousness.
Really need to keep it simple here as this will set the expectation and understanding for Stage 4 when more accuracy and complexity can be brought in.
Below shows an example of all the elements brought together and the final overall assessment of the Business Capability.
There are some summary insights immediately available from the above heat mapped model further drill down investigation should be done in these areas.
Like many fairly successful medium size businesses it is poor in:
- Business Planning
- Risk and Legal Services
- Information and Asset management
Business Planning: The worrying lack of maturity highlights a possible cultural issue – perhaps the CEO drives the strategy by his or her whim, gut feel or knee jerk reaction? Here is something that Enterprise Architecture can definitely help in, particularly ensuring that the project portfolio is addressing the business needs correctly.
Risk & Legal Management: They are spending more time and effort on the core business of selling and delivery products. Nothing wrong there, except of course a potential lack of resilience. A closer look reveals that systems and process (which is probably ad-hoc and possibly under-resourced too, (areas covered in stage 4) is bringing down the scores for the Legal Capability. This creates risk, yet the risk management area is also in a poor state too – so they won’t know until it’s too late if a contract fails, a suppliers fails or a dispute deteriorates beyond repair. Ironically it maybe best to address the risk area first (particularly processes as shown) before prioritizing any other work such as Legal.
Asset Management: The business is not a asset driven company and so the low score in this area would once again be protected by good risk management.
Data Management: The smattering of poor scores for information/data, with good scores for technology would imply that decisions are made on technical features and less on sound information management, which is supported by the poor IM score, even though there is good technology there. It’s very possible that some focused data clean-up projects in the order system will improve the situation, reduce the need to invest in technology and most likely help the risk management side capability too.
A quick look at the projects provides some further evidence of the tactical approach to business planning and therefore investment.
The aim here would be to influence the next round of investment to become a little more strategic and possibly less tech-feature focused. Note: just because the first project mentioned “strategic”, it may not be – and its drivers are clearly cost reduction.
Step 3 – Link Data Entities to Interfaces
This is now a great opportunity to improve your interface catalogue by linking the Interfaces to the Data Entities, and adding to your Data Entities catalogue. By doing this you are starting to define the data flows between applications. It will not be accurate, it will be an approximation in some cases or just a high level. Although if you can at this point actually drill down into the interfaces (perhaps due to a project on the go) then it’s very worthwhile to improve your interface catalogue with information from your interfaces specifications. Even if it’s just a link to the interface Spec, or a simple list of data fields in the Data Entity Catalogue.
Once again the urge to “stop the world” and document down to the lowest level must be resisted. This is an iterative exercise and we are just laying out the structure for later enrichment. Over time as each interface is further documented you will be improving your knowledge of the actual data and your integration requirements which in turn will lead to a view of your integration strategy. But concentrate only where it counts.
Step 4 -Add a Server Catalogue linked to Applications and Locations to develop a Geographic model
Its time now to bring in more detail about the underlying technology that supports your applications. These days we have quite a mixture of SaaS cloud and IaaS cloud and still some physical or internal servers, so the next important layer is the server infrastructure. We also have complexity of some major applications with multiple servers.
The objectives are to highlight any infrastructure that is NOT fit for purpose so we need to collect Operating System and versions including whether we have any physical servers and whether the location is pertinent.
I have seen these exercises revealing (in one major organisation) that core Applications were hosted in the US while the majority of the users were in Australia – this explained the were perceived performance issues, due to the natural latency of thousands of kilometres.
But in some situations location may not be that relevant, except to show how many cloud SaaS application you have to justify an increase in Internet Bandwidth perhaps?
There is not enough space in this type of article to unpack all the possibilities available in this most important foundational stage of architecture, it is also very dependent on the needs of the organisation and the maturity, capability and readiness of the delivery and executive teams to be able to absorb the sometimes subtle and at other times controversial insights or outcomes. There are also a number of paths that could be followed to enhance and capitalise on the information delivered that could shape the outcomes or deliverables.
In many instances your customers may not be ready for this and its best to just pack up the shelf-ware and wait for the next cycle. But in truth, all levels of an organisation have the ability to see the depth, strategic significance and therefore value of linking the architecture components and I have very seldom worked with people who actually are against the newly found insights. However resistance to change, fear of the unknown and particularly fear of the power of information (which is what we are creating here) may result in passive support and the resulting apathetic approach. In other words people will just ignore the architecture and just hope you go away. Analogies of water, horses and drinking come to mind, but every now and then one gets a glimmer of hope.
Just recently in fact, I sat with a CFO who was practically rolling his eyes in frustration for the first few minutes as I led him through our findings and architecture plan. Then suddenly it clicked as he realised that the design we were talking about was not just bits and bytes and flashing lights, but contained the facts about the core of his business and he saw that this architecture was a real tool that he could use to predictably design his business into a better place. It gave him the power he needed to help the organisation make collectively wise decisions.
“But this is what we should be doing anyway, right? It’s a no-brainer and makes total sense.”
…..were his words.
Stage 4 – Integral Enterprise Architecture
As a recap and preparation for Stage 4 we would have already built:
- Stage 1 – MVEA (Minimum Viable Enterprise Architecture) which provides us with the what (applications) used by the who (business units) that are both changed by the how (projects) and because of the why (strategy).
- Stage 2 – Digistising Architecture was where we placed all this in an easily accessible and useable online repository (using SharePoint as an example) with added business capabilities, some more technology and some interface information.
- Stage 3 – Foundational Architecture was where these objects are further improved by linking together more closely, and adding Process, Data Entity and Server information including an assessment of business capability. At this point we have the core architectural components linked together and we are employing a sophisticated data modelling database or architecture tool to support the complex relationships.
You can find out more about MVEA stages 1, 2 & 3 at this website: intron.com.au/mvea or by clicking on the links above to find the LinkedIn articles.
Stage 4 is called Integral because the objective is to move Architecture to become pervasively integral to a business such that it becomes part of the thought processes, without people necessarily realizing it. The design of a business, like the design of a building, is what you live with day-to-day and it has a huge impact on us all.
Winston Churchill once said “We shape our buildings and afterwards our buildings shape us.” This was in 1943 while considering the repair of the bomb-ravaged House of Commons. It is now well understood that the design of a building has large impacts on humans for a lot reasons. The architecture of a business has, I believe, similar impacts on our working life. Perhaps not in the areas of aesthetics or space but all the other things that make up working life including processes, information available, direction and strategy, of course the technology we use and very much our own (human) mind in all of that. The better we understand the architecture of the business we work in and our place in it, the more we can contribute and therefore out of it.
Stage 4 is where Architecture impacts the business strategy, culture, personality and customer service just as much as it does the efficiency, effectiveness and financial soundness, for it comprises the holistic design of the business or organization.
The Architecture Repository now looks something like this:
NOTE: It is essential that a fully featured relational database is managing your data and that an effective architecture or data modelling application is used.
Four Steps to Stage 4
Step 1 – Customer & Service Driven Strategy
- Link assessed Roles to Capabilities to enhance this models
- We now have the full picture of a capability and can use science to manage performance and direct investment at the capability level. To find out more about Capability Modelling, click here.
Step 2 – Business Capability Managed Change
- Add Services & Products and link them to Business Capabilities & Org Units
- Now we know how Business Capabilities (people, process, technology & information) affects customer services and products. We can therefore model and measure more accurately where investment in a capability will impact customer services/products.
Step 3 – Top to bottom – Channel to Infrastructure Measurements
- Add Network, Security & Integration Models – linked to servers of course.
- The infrastructure layer is now practicably completed and this direct linkage can go right up to the business architecture. For example, the impact of a network outage, or security breech can be modelled and scenarios planned for including business service impact and, of course investment can be tracked.
Step 4 – End to end – Organisational Communication Interfaces
- Link Organisation to Locations to enhance your Geographic Model if relevant
- Essential in the larger geographically spread organisations in a macro sense, where the spread is around the country or globe. However at a micro level, within one building or floor, the interactions between organisation units can have significant impacts on communication between teams. The modelling of these interactions can add value to a capability.
Step 5 – Holistic Insights
- Include, where practical, financial information about operating costs, specifically technology costs and people costs. Use of the TBM taxonomy and categorisation of your technology architecture components to help with this. It will be harder to do people costs, but Org.Unit opex. budgets can help here.
- We now have an almost complete model of the business, at least all the components that matter and are most impacted by change. The relationships and components may never be accurately modelled in a real-time or a detailed sense, but at the minimum one should be able to identify an area that needs more detailed analysis.
The vision is to create a holistic model that can be traversed or discovered to understand a current state, create target scenarios and model the results, producing impact analysis to more accurately predict time, cost and value in any change that is being considered. This supports the primary aim of Enterprise Architecture, which is to help the business make wise decisions. But the secondary aim is to influence these wise decisions because, with good holistic design information available, one should be able to identify, clarify and support innovation opportunities, steer away from wasteful change and lead the business towards valuable change.
Everyone can be an architect.
If you take a look at the plethora of reality TV series being broadcast you can’t help notice the rise in popularity of house design programs such as Grand Designs, Escape to the Country or Escape from the City (Australian version). Many people are fascinated with architecture, especially of our homes, and we all are wannabe architects. The appeal of design seems to be part of human nature because we are driven to create and invent. What more important place than our homes? It’s not only the structure of the walls, roof and glass, but also the interior design and a need to improve the utility of the place.
Yet, it is strange to me that this is not the same in business, after all this is where we spend more than half of our waking life. It is as if businesses (or many organisations) are created by just throwing together a bunch of people, divided into roles with some ill-defined processes, using some arbitrary tools. This is then grown organically into ever more and more complex organisations. Generally we just make it up as we go along, based on previous experience that seemed to work then. Many of these “designs” or business models, let’s be honest, are a few hundred years old.
People as soldiers
Firstly, we tend to use military-style hierarchical structures to create our people organisations, which are based on two-thousand year-old Roman ideas. This does creates clear accountability in a few individuals and is known as a centralized approach to organizational structures, which is important when one’s communications channels are limited . Human communication has changed fundamentally in recent decades and even the modern military are changing and moving to a more devolved approach where on-the-ground command have more autonomy and utilising extensive communication technology to keep everyone aware of what is going on – sometimes termed Network Centric Warfare.
Processes are machines
When we do create business systems we tend to design them as machines, with standard inputs (sales) and outputs (revenue) and in this machines we are small cogs (human processes to be later automatde) that will all work in the standard and normal “best case” scenario. These systems often can’t deal with changing requirements and environments and so we rely on humans to adapt and innovate to deal with the “edge” cases. Like any 20th century machine, as long as the input is the same, we can guarantee the output. Except business is not like that, it changes all the time due to legislation, customer needs or desires or new technology.
Project Management: bridges or software?
However when we try and build these systems we use inappropriate methodologies. Some are best suited for building bridges or large infrastructure items (commonly known as the Waterfall method) or another that is suited , in fact design for, developing software (commonly termed the Agile Method or sometimes Scrum). Neither are actually suitable for developing business systems. Why ? Because they both generally ignore the human element, which is why many attempt to add human oriented design and Change Management to an I.T. Project. But there are a number of other components that could impact the design of a business system which are often ignored – just look at all the components in the diagram above, they include: Infrastructure, Services, Financials, Geography and all the complex inter-relationships.
The current project methodologies are designed to just get things done, quickly and in-budget, then move on. Important of course, but not holistic, exhaustive or complete.
But Enterprise Architecture and a repository is not a solution to this, of course, but as a holistic model of the design for your business it can help, at least, in defining what components need treatment and inform the choice of appropriate methodology. (Note: It’s Technology Architecture that informs the choice of Technology)
A theme of MVEA stages 1-3 is about creating a visualisation of the enterprise from the data-based model we create. This is important because generally people can better grasp visual representations and it’s a great way to communicate complexity. But if you only draw pictures then the model does not persist, so it is essential to capture that model in a database as you go.
If Enterprise Architecture is the design of your business, then you will need to:
- Create a model that people can see/visualize (like the Grand Designs models of houses). Preferably one that people can interact with to update, correct and experiment with as well.
everyone involved in designing it ( it’s complex and there are many parts)
- We all intuitively know that innovation must come from all parts of the organization, not just in an Innovation Centre.
The problem is that current business architecture is not particularly visible.
Think of these components that make up Enterprise Architecture:
- Applications – this is code running on a system somewhere. Users only see the front end that allows them to input or extract information.
- Processes – these may be documented somewhere, but generally are held in people’s heads. Except for Call Centres that use scripts, most people would not know they are following a process even when the software they are using is actually taking them through a process.
- Services – intangible things people use or consume. Not something you can lay your hands on.
- Information – we only see a small portion of the information the businesses use, yet the amount being processed is growing exponentially.
- Servers and hardware – either hidden in a data centre or nowadays literally virtual as they are in “the cloud”.
- Financials – we only see reports of numbers, never see cash (except for coffee shops)
The only tangible elements of any business are:
- People and
- Products ( but only where the product is tangible like in retail).
All of the above are becoming less tangible and visible as we move more online and therefore it’s becoming more valuable to build an Architecture model and create these visualisations to allow people to understand, update or hypothesize. Not only the decision makers that we were targeting in stage 1-3, but also anyone that is creating or managing change, or creating a plan or strategy (business or otherwise) that impacts the business architecture or the business as a whole.
Therefore everyone can be an architect and we should encourage that and capture their designs.
The role of Enterprise Architect can then grow closer to that of a building or urban Architect.
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.
Add alt text
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.