Conference Image

EAS’s View from the Gartner US IT Symposium/Expo

We had a good week in Orlando at the Gartner US IT Symposium/Expo, it was interesting that there were some consistent themes that came up in our conversations with CIOs and senior IT leadership regarding enterprise architecture:

A lot of work

We had several conversations with people who had the perception that EA management tools meant that lots of data were needed. The concerns seemed to be twofold: first, if you had an EA tool then you would be duplicating data that was already in other systems, and second, that business value required lots of data that would need to be collated.

The first concern is easy to address. If you have other systems containing the relevant data, then they should be feeding that data to the EA tool. The EA tool should be a hub for that data, collecting it from other systems and enabling its enrichment to provide a holistic architecture view.

The second concern is a misunderstanding as to how you approach EA tool success.  Whilst the goal is to create a complete view of the enterprise and its interdependencies, this is often a long-term, multi-year effort and, for many organisations, ultimately unrealistic. Anyone suggesting otherwise falls into the “charlatan club” (a group far too common in IT) who claim expertise while lacking any true experience.  The best approach is to see your EA as a journey, with value drops as you go along: map out your objectives, look at what data you have available and then work out the simplest route to deliver those objectives.  Small, fast value drops are better than large, slow ones.  They key word is value, so work on things that people can make use of, which may be as simple as an application catalogue to start with.

Not sure where to start

Quite a few people were starting out and weren’t sure where they should start their enterprise architecture initiative.  Similarly to the above, it’s about defining what value looks like for you and your organisation, looking at what data you’ve got available, and then delivering in small steps.  Typically, a simple, consolidated application list is valuable and so provides a good starting point.  Mapping this to business capabilities then allows you to show where there are areas of potential opportunity. From an enterprise architecture perspective, it’s useful for communication and buy-in, but the real value lies in identifying whether those opportunities are real or not.  Alternatively, getting a view on vendor lifecycles for products can be useful to see where possible risks exist.

Focus on value

A key point is to focus on the value that you can bring to your organisation, several people asked how you deliver value.  This is about understanding who the key stakeholders are, the main issues that they face or the key questions that they are unable to answer or address, and how you can assist.  This will vary from one organisation to the next but will typically fall into a few common categories such as needing to reduce costs, being more agile and responsive to the business, reducing risk, and demonstrating plans to deliver strategic alignment.  Once you have identified your key stakeholders and their key issues it should be easy to deliver value.  Interestingly, a number of people who asked this were the CIOs, so we said tell your teams what will help you do your job better, there is value to be had from enterprise architecture on multiple fronts, so give the architects clarity and focus on what you need, but don’t spread them too thin with too many demands.

EA Journeys

Linked to much of what has been said elsewhere in this blog, several CIOs asked how enterprise architecture can be effective.  We talked about how you should get your teams to treat EA as a journey, set a target, have a set of points where you expect value to be delivered, some small, some large but all tied to value, and then get the EA team to follow, and report progress based on, the journey.  There may be multiple paths at some points (not too many) but keep the journey coherent and make sure each step is deliverable.

If an EA management tool is part of that journey, and we argue it should be, then for organisations that simply throw data at the EA tool and look for insight, the only insight they are likely to get is that they wasted money on an EA tool. Instead, they should tie the EA tool to the journey and only capture data that supports the journey.

Lots of reboots, so early days

Several of the people that we spoke to had seen multiple reboots of the EA Team/EA initiatives and so wondered if the introduction of an EA management tool had a role to play in helping deliver value.  As we always say, “focus on value, forget the rest”.  If the EA team is delivering tangible value, it will be a success.  If the EA is seen as an ivory tower, a team that is only internal facing or a team that actively blocks rather than facilitates development and business support, then it will fail.  If you are rebooting, then it is likely the original team didn’t focus on value, potentially focusing too much on delivering a framework than on what the business needed.  The tool has a role to play if it can help you deliver that value. If well targeted, it should deliver faster and quicker insight, highlight opportunities or risks better, and communicate more effectively.   Understanding your stakeholders and their issues, and then addressing those issues is the route to success. The tool can support you in that.

Keeping it updated

We heard lots of war stories about the amount of data required and the difficulty in keeping it updated.  At EAS we believe that the people with the knowledge should update the EA data as part of their job. (As we’ve argued in previous blogs, “Everyone’s an Architect”). This shouldn’t be a one-off task or a job for a centralised team.  For example, when a solution architect implements a change to an application, or an integration architect updates a feed, or a business analyst updates a process, these changes can be captured in our Essential tool using our editors/web forms.  These are easy to use, and they need no training or enterprise architecture knowledge.  Make this part of your governance/change process and you’ll go a long way to being successful.   This won’t happen on day one but a planned out initiative will see the wider organisation engage over time.

Also, don’t capture what you don’t need, unless it is valuable data and can be maintained, then avoid capturing data for the sake of it.

 

Diagramming can lead to chaos

When adopting an open diagramming approach, repositories can become cluttered with many duplicate or nearly identical entries. As one CIO put it, “We’ve managed to create a mess in our current tool; it’s chaos.” In contrast, our move to diagramming has been more cautious, maintaining control over what is added to the repository to ensure that data is thoughtfully considered before inclusion. This was well-received at the conference, as people appreciated that our approach means a much more reliable dataset to base their decisions on.

Useful Links:

5 Tips for EA Repository Success

Enterprise Architecture – Simple Wins to Show Value

Effective Enterprise Architecture depends on powerful Governance

Collective Wins – How Enterprise Architecture and Regulatory Compliance can create Mutual Success

Using Storytelling to engage your Organisation with Enterprise Architecture

Contact Us