Blog Series – Where should I start with my EA?

Play 1 – Anchoring on Applications, Bringing in Business Elements

When someone takes Essential, our Enterprise Architecture Management Tool, we are often asked where we would recommend that they start with their EA.  Being Enterprise Architect’s, our answer usually starts with “It depends…….”!!  But in truth, it really does depend.  The two key factors that need to be considered are; where are the biggest ‘fires’ in the organisation, i.e. what is everyone concerned about/shouting about, and what information  can you get hold of quickly?

The first thing to understand is who your key stakeholder is and what is keeping them awake at night.  If you can provide information that will support the decision analysis around this area, then that is a great start.  The second is to understand the information and data you will need to capture in order to enable this – if you can utilise data you already have access to, wherever and however that is held, then you can respond really quickly, in a matter of weeks.

In this series of blogs, we’re going to look at common scenarios that we encounter and the initial steps we recommend.

The scenario we encounter most frequently is the organisation that has grown organically with a federated approach or through mergers and acquisitions.  In both cases we often find that there is a push for application rationalisation to provide efficiencies through both cost saving and speeding up IT’s ability to respond to the business needs.  However, this is often hindered by the lack of visibility of IT assets across the organisation and how they support the business.

Below are condensed extracts from our EA Playbook that describe how to manage this scenario and to achieve a positive outcome.  The playbook assumes you have a target state defined for your IT estate, so you know where you are going, and against which you can anchor your work.

Before you start, the key things to note here are the pre-requisites to starting the play; it is imperative that you have the support of a senior leader and that they communicate to the IT Teams, and also that you have access to a friendly business contact with excellent knowledge of the business.  Once you can corral the data to produce an application list with the links to the business overlaid, you should expect to be able to engage both the CIO and the business leaders in conversations about exactly where efficiency opportunities exist.  By presenting your architecture models in a non-technical way that can engage senior leaders, they will be able to see clearly where there is duplication and understand why application X costs them more and why application Y slows them down.  Identifying the ‘low hanging fruit’ in terms of cost savings can provide a springboard for moving forward in allowing IT to become a true partner with whom the business want to engage to meet their strategic business goals.

The approach we’d suggest is:

  • Publish an up to date application catalogue
  • Engage the CIO by using the application catalogue as an anchor to create an application reference model and then identify duplication within the application estate from a capability perspective
  • Engage with your business contact to overlay the business view and identify potential duplication from a business perspective. Start with one business area and complete that first as a demonstrator
  • Bring in costs for those areas of interest, i.e. where there is application duplication
  • Start to understand complexity of integration for those high priority candidate applications

Some of the key Essential views that support this approach are:

Business Application Footprint  (See live view demo here)
Key business architecture view showing how applications map to business capabilities, with TOM and capability differentiation.

Application Reference Model  (See live view demo here)
Shows Application Capabilities and Services, with Applications mapped.  Highlights duplication across application services.

Application Rationalisation Analysis  (See live view demo here)
Displays opportunities for rationalisation across applications and application services, with various filters for specific criteria.

Business Process Family Summary  (See live view demo here)
Shows all the business processes contained in a process family, including performing organisations and applications used.  Highlights where there are non-standard processes and different supporting applications used across the organisation, supporting the identification of opportunities to re-engineer and automate processes.

We’ll be publishing extracts covering different scenarios on a monthly basis.  If you’d like further details on the scenarios or playbooks please contact us here.

Are open source EA tools as good as commercial tools?

One of our users/advocates this week pointed us at the FAQ of one of the commercial EA Tools where they state that free and open source EA Tools are only useful for rudimentary EA requirements, whereas commercial tools, like theirs, are much more advanced.  It struck us that this is either a poorly informed organisation, unaware of the competition, or lazy writing by someone who does not understand much about open source.  We normally ignore the competitors and let them worry about us, but in this case, we do feel it is important to respond to something that is clearly misleading.

They state that only commercial tools can provide business outcomes and decision-making insights through a central shared repository, an integrated set of views covering strategy, business, applications, information and technology, to provide the insights necessary to optimise, rationalise and transform.

There is, however, nothing in that statement that can’t be delivered by Essential Open Source – a free EA tool.  Far from supporting only ‘rudimentary’ EA requirements, Essential Open Source is, in fact, a very sophisticated EA Tool that is focused on providing decision support and “what if” analysis to EAs and CxOs.  In addition, Essential has a world leading, ontology-based meta model and has been designed to be exceptionally flexible – the meta model can be extended in minutes and new views can be created in hours by users.

The only areas where Essential Open Source falls short is that it is not Cloud based, it has to be hosted on site, and it has basic user permissions.  Enter Essential Cloud, the low-cost Essential Cloud solution that is, as the name suggests, cloud based and includes full user security permissions across both data entry and the viewer.  Oh, and did I mention it covers unlimited users.

I’m inclined to think the traditional EA Tool vendors, with their high costs and inflexible models, are trying to muddy the waters with this kind of article.  Have a look at what Essential has to offer and make your own decision.

Essential Key Points:

  • Over 120 out of the box views – have a look at the Technology Product Selector, the Application Rationalisation Analysis and the IT Asset Dashboard as just a few examples where the traditional commercial tools can’t compete
  • A free launchpad to get you started, with a simple data capture mechanism, to allow the population of 20 key foundational views across business, application and technology
  • Open Source or Cloud – Docker coming soon
  • Low Cost
  • Flexible
  • Built by architects for architects

Essential GDPR Launched

Our GDPR pack is now ready for use.  Unique in the marketplace, it supports business questions such as ‘do I have a legal basis for using this data?’ and ‘have I captured the client’s consent?’ as well as technical access and security questions, such as ‘where is my data most at risk?’.  Most other tools are focused on one or other end of this spectrum.  High level dashboards show where the GDPR compliance issues exist, and drill down capabilities allow you to hone in on the exact process, application or technology that is the cause of the risk.

We have partnered with UST to, optionally, incorporate the use of their ground-breaking data discovery tool which can identify structured and unstructured GDPR data in databases and document stores across the organisation. This not only eases the burden of data capture but also provides an invaluable cross-check of information provided through more traditional means.

A sample of the dashboards are shown below, or you can read further information, access the GDPR demo viewer, or sign up  here.

IRM UK EA Conference – Outsourcing and EA

I presented a session on Outsourcing and EA at the IRM EA conference last week; specifically how, as Enterprise Architects, we are in a prime position to ensure that outsourcing deals are both created and run effectively as we are in the unique position of having the knowledge and understanding of both the business and IT across the entire enterprise.  We likened EA’s to the Spartans in the battle of Thermopylae who held off an army of (allegedly) a million men for seven days with only 300 warriors – primarily because they understood and had a map of the landscape.  (Unfortunately they were betrayed and slaughtered after a week – hopefully the analogy doesn’t stretch that far!).

Research by both Gartner and AT Kearney suggests that around 1/3rd of outsource initiatives fail.  We discussed how use of our architecture knowledge and artefacts can mitigate the risks of failure and how EA can be used to bring greater success.  We touched on our work to help organisations use EA and Essential together to reduce the outsource transition time (from idea to completed transition to a new provider) from a typical 18-24 months to 6-9 months, which addresses a key concern raised by the FCA.  We showed some examples of how Essential has been used to support such initiatives across a number of organisations.

The conference itself was very interesting and it seems to me that EA is really coming of age – there were many talks showing how EA is used in organisations to provide real and concrete benefit to senior managers.

If you would like a copy of the presentation then drop me an e-mail at the info at e-asolutions.com address.

Essential Information and Data Pack

It’s been a couple of months since we released the Information and Data Pack and I thought it would be useful to take a more detailed look at what is in this extension to the Essential Meta Model and what it can do for us.

 

Firstly, thanks to our community members who have given us some feedback and found a couple of small bugs in there. We’ve started a forum thread to catch any more issues as we find them but will be releasing a patch and new version of the pack in the coming weeks – we wanted to make sure we had as many issues addressed in a single update as possible. If you’ve found any issues in there, please let us know in this forum.

 

This optional extension pack is a major extension to the Information layer of the meta model but although there are some tweaks of the core meta model elements, this is mostly an extension to what was already there.

 

We have added a number of important meta classes for managing Data elements and the relationships that these have to Application, Information and Business elements, enabling the resulting models to support Enterprise Data Management and Enterprise Information Management activities. More about that later in this blog.

 

One of the most important concepts in the pack is the separation between Information and Data. We have defined strong semantics for what is Information and what is Data, so that there is a clear and consistent framework for capturing and managing these elements of your Information and Data architecture.

 

We’ve based this on the commonly used “Information is Data in context” definition. Data elements have the same meaning and value regardless of the context in which they are used, whereas Information elements differ depending on the context. e.g. Product data means the same things regardless of whether we are looking it in the context of Stock, Sales, Manufacturing. That’s not to say that we only have one Product data element in our architecture, we can define as many variants of how Product data is managed in our organisation as we need – in terms of the attributes and relationships. e.g. Product Item data might have a different set of attributes to a Bill of Materials data object.

 

In contrast, Information takes data and uses it in a particular context. e.g. Stock Volume by Location might use data about Products at particular locations in the organisation and would have a different value for a single Product depending on the Location.

 

This separation of the Information and Data fits neatly into how we need to manage these things in the real world. Data combined and used to produce the Information that we need.

 

Naturally, we’ve used the Conceptual, Logical and Physical abstractions for the new Data metaclasses, covering the WHAT, HOW and WHERE for data elements. In addition to adding these new meta classes, we have created powerful relationship classes to them that enable us to clearly understand how Information and Data is being used by Applications and Business Processes. Some of this might seem a bit complex at first glance but this is due to the contextualised nature of these relationships. What we’ve created are constructs that enable us to understand what Information Applications use and create and in the context of that, which data elements are used, specifically, to deliver that Information – and in that context what are the CRUD for the Information and the Data. We believe that having these types of contextual relationships is a uniquely powerful capability of Essential Architecture Manager but we haven’t added these just because we can but because without them we cannot accurately or even reliably understand what is really going on in our organisation with respect to Information and Data.

 

So, what kind of things can we do with the Information and Data Pack?

We have designed the meta model to support Information Management and Data Management activities managing all the dependencies that exist between information and data elements and also how these are used by Application elements and how they are produced by Applications.

 

More specifically, in combination with the Views that are supplied out-of-the-box, we can understand where issues exist with our Master Data Management solutions, e.g.

  • where are we mastering Product data?
  • how is this data being supplied to our Applications?
  • how does this compare to how data should be supplied to our applications (according to our MDM policies)?

 

As you will have come to expect, the supplied Views are easy-to-consume, hyperlinked perspectives that are designed to give valuable insights to a wide range of stakeholders – not just Information and Data professionals.

 

We can browse the Data catalogue, drill into individual subjects, see what Objects we have in each subject and how each of these objects is defined. Further drill-downs can take us to views that should how this Object is provided to the relevant applications in the enterprise and from where.

 

Based on the detailed CRUD information that we can capture in the model, we can easily produce CRUD matrices from a wide variety of perspectives, e.g. CRUD of Data Subjects by Business Capability, CRUD of Data Objects by Business Process – both of which are derived from the details in the model, which means that these are automatically updated as the content of the model is updated.

 

One of the most powerful Views is also one of the simplest. We find that providing a browser-based, easy-to-access place to find accurate and detailed definitions for all the Information and Data elements – and most importantly in easy-to-understand terms – is a capability that is quickly valued, in particular by non-technical stakeholders. Deliberately, there are no ERDs or UML class diagrams in these definitions. Rather, we can explore the catalogue of the Information and Data elements in a highly hyperlinked environment, providing an automatically generated data (and information) dictionary to the organisation.

 

In that context, we’ve introduced some nice little features that will be included across all the Views such as the ability to identify the content owner of particular elements or groups of elements. This means that if we see that the content on a View is incorrect, we can click a link and send an email to that owner to let them know that things have changed or that there’s an error in the content.

 

We recognise that while most of the meta model concepts for the Information and Data pack are straightforward, there are some more complex areas, in particular in the definition of relationships. As always, we’ve worked hard to keep these as simple as possible but the reality of how Information and Data is used and produced is (or at least can be!) complex and we need to able to capture and manage these complexities. However, the capabilities and results are worth the investment in understanding how to use these. For example, the way the Information to Application (and in that context, to Data) relationships work, enable us to understand how a packaged application has been configured in terms of how the out-of-the-box data structures are being used. This means that we can understand where Product Codes are being stored in Location Code tables, for example, and this is the kind of scenario where the ‘devil is in the detail’ and fine-grained things like this can become the source of a lot of larger-scale issues in the architecture.

 

We’ve already had some excellent feedback on the pack and based on demands from real-world use of Essential Architecture Manager, we are now looking to extend the granularity of the application-to-data relationships to include data attributes, rather than just data objects. You might not always need to go to that level of detail but if you do, the capability will be there – and this will be designed to enable you to model at asymmetrical levels of granularity.

 

Although it’s currently an optional extension, the Information and Data pack will be incorporated into the next baseline version of the meta model. We think that the game-changing capabilities of the Information and Data Pack are a vital part of the enterprise architecture model and so it is natural that this extension become part of the core meta model.

 

How can organisations justify enterprise architecture in a recession?

Following on from my blog of 19th May, How can organisations afford the luxury of enterprise architecture in the middle of a global recession?, a more detailed article is available for download from the News and Industry section of the EAS website.  In the article I examine the reasons why Enterprise Architecture has become so popular and focus on the areas of importance when budgets are tight, including application consolidation and project portfolio management.

Is Enterprise Architecture only for big companies?

I read Mike Kavis’ blog Is Enterprise Architecture only for big companies? a couple of weeks ago and I think that the points that he makes are spot on.  I certainly agree with Mike that EA is as beneficial for an SME as it is for a large organisation.  How can understanding more about your organisation and having that information to hand ever be a bad thing when trying to make decisions, whether they are regarding technology, people, or the focus for the future?

I am also in complete agreement that 20% of EA is better than none.  I wonder sometimes if people confuse accuracy with completeness here.  Certainly if you are working from the wrong information then this could be more damaging than having no information.  But partial information must be better than none, especially if you are picking the elements of EA that are important in that instance.  The key in any organisation, large or small, is to identify your most pressing business need and use EA to solve that need (see my blog from March 15th – Identifying the problems your EA needs to solve).  Some kind of framework is important in as much as you need a consistent approach to your EA efforts, but this is more pressing in a large organisation with many more architects, each with their own perspective!

As regards cost, if you have had a look through our website, you will have noticed that one of our aims is to make EA more accessible to SME’s.  It is our view that it is hard to ‘do’ EA without a tool (see Jason’s blog from Feb 19th – PowerPoint and Excel for Architecture Modelling; Why Not?), and that, to date, SME’s have been unable to join the party, so to speak, because buying and introducing commercial EA tools often requires significant investment.  We hope that Essential, being free and relatively easy to install and use, has removed at least this barrier.

The Devil is in the Detail

If architecture models are to be used to help make decisions about change in your organisation, those models must include details that reflect complexities of the real world.

The Problem

I am frequently asked what is becoming for me a classic question, “How far should I go with the detail of my model? When do you stop?”

In general, I would say the more information you can capture, the better. We do need to be able to “see the wood for the trees”, though. We don’t want to get lost in the detail – both from a point of view of the sheer volume of information and also from the perspective of capturing things that are not currently interesting.

Many models and frameworks tend to stay at quite a high level. This can be OK for some scenarios – e.g. high level design or a Powerpoint. However, detailed decision support enabled by information from the architecture model requires the detail. If this is not available then all too often, when the details come to light, they break the model.

When interacting with other parts of the organisation, architects who gloss over the details, can often be perceived as ‘arm wavers’ and can quickly lose credibility – even though the ideas themselves may be sound.

In the increasingly technologically educated world, you ignore the details at your peril. The very systems that we have to manage, as Application and Technology Architects, are becoming more and more complex. The Cloud, SaaS can provide significant benefits but the services that they provide still need to be managed as part of the Enterprise Architecture. The ‘details’ are still there but now we’re not directly in control of them. We cannot just ignore them because we have a service provider that manages how that service is delivered.

Really, we need to be able to ‘roll up’ the detail when required. Also it would be great to be able to easily come back to elements of the architecture that we didn’t initially capture to any great depth, and enrich the detail later, when we have it.

I’ve used some technology examples above, but the need to recognise the details exists just as much in Business Architecture. One of the big issues here is that we cannot ignore IT when looking at the Business Architecture. It is the reality of today that nearly every process in the organisation is supported by IT in some way.

A Way Forward

So, how can we manage the details without suffering information overload or finding ourselves in a modelling equivalent of painting the Forth Bridge?

Generally, details are missed because when we uncover them, we have nowhere relevant to capture them. So they are ignored or forgotten. If we could capture all the relevant details as we find them – and model them so that everything we know about some aspect of the enterprise can be related as appropriate to others – this would really add to the organisation’s ‘knowledge base’.

Now, modelling of this nature requires a detailed ‘language’ if we are to be able to reflect the nuances of things at the detailed level. However, this language must enable us to “black box” elements in the model – to save us from getting lost in the detail and deal with them at the right level of granularity for the activity that we’re working on right now.

The important thing about not ignoring the details is that our model needs to reflect the real world if we are to be able to make effective decisions from the knowledge we have captured. This might mean that the modelling activity or the model itself requires some complexity. We cannot hide from modelling complex things when they are truly complex in the real world.

The ability to capture the required details yet roll elements up as “black boxes” is one of the key drivers behind much of the development of the Essential Meta-Model. We started with a simple set of core concepts and introduced additional concepts incrementally to manage the detail as we found we needed it.

Don’t get lost in the details of your enterprise. Embrace them and manage them locally, in their relevant context (don’t worry about the servers if you’re looking at how your applications support your business processes!). Understand how these contexts, which are the layers and views of the Enterprise Architecture, fit together and the details will take care of themselves.

If something’s hard to do, then it’s not worth doing – Homer Simpson

The above quote from Homer Simpson could be applied to a lot of people when they consider embarking on Enterprise Architecture for their organisation.  Luckily, I’m not one of them!
In principle Enterprise Architecture isn’t hard at all.  I was trying to explain what I do to a friend of mine who is a builder/runs a swimming school and he couldn’t really understand the issues.  It seemed inconceivable to him that an organisation could have little understanding of the applications they are running and all the links between them; or no understanding across the organisation of the business strategy and what changes this would require from the business and IT communities; or be running two applications that actually do the same thing; or have two processes that achieve the same result.
This, of course, is symptomatic of the difference between a small business and a large global organisation, but it highlights that in principle Enterprise Architecture is a no brainer.  You simply need to understand the processes that your people are going to perform to achieve your business strategy, the applications that will assist them, the information that the people and applications will require and the underlying technology that will allow the applications to run.  Once you have this understanding, making adjustments, whether to streamline your business or because of a change in your strategy, is easy.
Of course, in practice ‘doing’ EA is never easy, and the ‘understanding’ element is only part of the equation.  Even if you understood all the elements listed above, achieving the ‘control’ required to manage change is still a significant challange.
Nonetheless, contrary to Homer’s advice, even though doing EA is hard, it is definitely worth doing.

What are the Essential Project Team up to?

If you’ve been keeping an eye on the forums you’ll know that we’re in the process of putting together a sample repository.  The sample will take a fictional investment management company as an example and show a thin slice through all the meta-model layers to demonstrate the linkages between the different architecture concepts.  We chose an investment management company as it’s an area we know well, but also because we think it is broad enough to be understood without having to be a domain expert.  We’re currently populating the model and are expecting to get it out in the next couple of weeks – time permitting.
Something we’ve been asked a number of times via the forums is for a pictorial representation of the meta model, showing the links within and between layers.  We have been working on this and it is nearing completion so we hope to have it up on the site within a week or so, again, time permitting.
With many people trying out Essential now, it would be great to hear views on it, and ideas as to where the tool, the website or the documentation could be improved.  Please do let us have your views on the Forums.