Author: iandick

The 3 Types of EA Metrics

There are 3 fundamental ways to measure the performance of your EA team:

1. Measure IT
IT metrics are well established — ROI, Total Cost of Ownership, Mean Time to Repair (MTTR) etc..

Such IT metrics are SMART and appeal to the business. They are good measures for IT — but do they translate to EA?

In theory the EA team should be able to increase ROI for IT, reduce Total Cost of Ownership etc… However, there are many factors affecting these measures. The correlation between EA performance and IT metrics may be low.

2. Measure EA Governance
It is relatively easy to measure the success of IT governance. What percentage of projects complied with governance? What percentage of projects were rejected? The problem with these metrics is that they lack appeal for the business.

It is not obvious how governance metrics translate into competitive advantage, customer experience or cost savings.

3. Measure EA Itself
Measuring EA directly is the ideal way to score the EA team. The problem is it is tricky to develop such metrics. The EA team collaborates with business, solution and governance teams.

The fact is that it is difficult to assign a number to collaborative long term planning activities such as EA.

EA is Strategic Planning

Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed.

How does an enterprise react to events that do and will potentially occur and arrive at the strategies needed to remain robust, efficient and viable, to continue to deliver value and make profits for themselves?

Enterprise Architecture is the corporate discipline that helps us to understand the questions that need to be asked and get better at strategic thinking. The approach is based on asking the usual Why, What, How, When, Who and Where questions:

  • Why does the enterprise need to change?
  • What are the drivers for change?
  • Are the drivers fully understood?
  • What is the mission and purpose of the enterprise?
  • What do enterprises need to do and need to understand? What do their customers and stakeholders want?
  • What is possible to do?
  • What are the strategies, goals and objectives?
  • How will these be achieved?
  • What business capabilities are needed?
  • When should the enterprise react to new opportunities? What are the potential business scenarios that might occur? How will the enterprise react when they do occur? And how should it react?
  • Who should be involved?
  • Where is the enterprise?
  • What environment or markets is it located in?
  • How many different environments are there?
  • What would success look like for strategic planning?

These should all be open questions. You should take care that the questions don’t upset those executives that are responsible for the current answers and are asked in an ego-less fashion.

All of these answers can be modelled and analysed with your favourite enterprise architecture tool.  I like to add a Strategy domain to the usual Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture domains.

Enterprise Architects should start to think like a strategist instead of just like a technologist.

From https://ingenia.wordpress.com/2013/01/20/ea-is-strategic-planning/

Lego Board

Prototyping to learn

The team started by quickly building a prototype wall using index cards with  mail-merge stickers on them describing each procurement project. This information had previously lived in a spreadsheet. With the work quickly thrown up onto a wall, they asked themselves the question: “What is this wall not telling me?”.

Answer: a lot! There were so many cards it was hard to see what was going on. They were hard to read. And the wall couldn’t tell the team anything about cycle time: how long was each project taking to go through the whole procurement process?

Additionally, one of the team members had a visual disability, so the team wanted something with high contrast and large lettering. This was going to be hard to achieve with cards, given the number of procurement projects which were in flight at any time.

With this learning, the team built a second board, this time from Lego.

From https://agileboardhacks.com/2015/08/28/lego-board/

Seven questions to build a roadmap

Ask 7 simple questions

Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask them these questions*:

  1. What are we trying to prove or learn?
  2. Who are the users?
  3. What are we operating?
  4. What are we saying?
  5. What are our assumptions?
  6. What are the dependencies?
  7. What capabilities do we need?

A timeline is not dirty

The Waterfall methodologists feel comfortable with long timelines.  They typically work ‘right-to-left’ from a desired delivery date;  the agilists prefer to work iteratively, ‘left-to-right’ as much as, and where possible.  Whatever your preference, timelines are important and an inescapable part of delivering.  A timeline is not a dirty concept.

I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate “deadline” in everyone’s head and to get them to think strategically.

Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don’t become the only focus of conversation.

From http://www.jamiearnold.com/blog/2014/07/22/seven-questions-to-build-a-roadmap

Weekly Digest

Life
Autumn has landed – from a gorgeous day on Saturday to…well…shitty rain and wind. Glad I got out and about up North yesterday and saw some of the Autumn colours.

Also been using the new Apple Watch for over a week now and really enjoying it. Big upgrade (for me) over the Series 0.

Media
Doctor Who – great first episode. Jodie Whittaker nailed it, the writing and story were pretty good and the reworked music also landed.

Ant-Man and the Wasp – watchable follow up although nothing very original about it.

Forza Horizon 4 – stunning looking game. Set in the UK and really enjoyable first few days with it, even if the streets are too clean.

Links

Ten Ways to Kill An Enterprise Architecture Practice

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

From http://blogs.msdn.com/b/nickmalik/archive/2013/09/05/ten-ways-to-kill-an-enterprise-architecture-practice.aspx

EA Generalist

A generalist knows a little about a lot of things, and, crucially, how to connect them together. Good generalists are well aware that they are actually quite small fish in what is often a very big pond.

A specialist knows a lot about a single often very-little thing. Good specialists can be quite big fish, though only in a relative sense within their own often quite small pond.

You can’t be half agile

Combining agile and non-agile into a jerry-rigged mishmash misses the point of working in an agile way.

Being agile doesn’t mean you give up on governance or deadlines. The idea that agile somehow “needs” a waterfall-type methodology to give it control and governance is nonsense. When you work in an agile way, governance is built into every step of what you do. You build and iterate based on ongoing user research. You build what users need, not what you guessed might be a good idea before you even started building.

Weekly Digest

Life
A bit late with the update. On holiday from work (back tomorrow) and busy fixing the house, taking photo’s and flying a drone. Normal stuff really. Links this week are pretty Apple heavy – fun fun fun!

Media
Solo – average film and would have probably ditched it half way through if it wasn’t a Star Wars movie.

Bodyguard – well done all involved. Stuck the landing and plenty left to take another series forward.

Links