The Future of EA is no EA

An excellent blog post by Jeff Scott from Forrester on the future of EA has got me thinking about the most likely future state of EA in DCC.

The most obvious future and one which i entirely agree with is that EA as a function will disappear in time. My previous post about mainstreaming ICT functions supports this view as everything becomes a core business competency. But what happens between now and then and what direction are we really moving in and more importantly what direction will the organisation accept us to move in?

In my personal opinion i would suggest the there are two options which are most likely in DCC over the next few years and i think we are likely to end up with both of these scenarios:

Scenario 3: EA remains in IT, largely focused on technology architecture.This seems to be the most likely outcome for small to medium sized IT organizations. In this option business architecture will be developed primarily as input into the technical architecture. The key to success here will be for EAs to evolve from technology planners to true IT strategists.

Scenario 4: EA remains in IT but becomes more business focused.This model will be prevalent in medium to large IT organizations where IT has developed a strong partnership with the business. Here, EAs will be welcome at the business planning table and will be well regarded by business and IT for their ability to match business needs with IT capabilities. The business architecture focus here will be business-IT alignment. EA’s resources will be about evenly split between BA and technology initiatives. Successful architects will be very business savvy but keep their technology roots.

There are some justifications behind my thinking which i will share with you now.

Scenario 3
The likelihood of this future is related to a number of key factors – the ability for the EA team to maintain business people within it.  If this is maintained then this future will become less likely, however without real Business engagement and acceptance across all areas of the organisation to the benefits of Enterprise Architecture as an approach and not just conversations between ICT people and Business people trying to bridge the gap, then we will inevitably resort to Technical Architecture work.

Scenario 4
The likelihood of this future is already taking shape, our new ICT strategy is very much business focused and we already have a team in the business who are leading on Information Architecture. The challenges for this scenario however are again the ability of the team to engage with Business people and to maintain the business skills already developed in the team. However i would suggest that over time the focus of the team will be driving the technical architecture in response to the business. I also think that the business architecture function will not only be about Business/IT alignment but the architecture of the IT function itself.

If we get to a point where the IT function has had appropriate levels of business architecture then it would seem a likely next step to embrace Scenario 1 and 2 – The EA team disappears as a unique function and is absorbed totally by the Business as a core competency.

In my humble opinion we would have succeeded as an Enterprise Architecture function if this outcome is achieved.

Advertisements

Communication

We are doing a lot of work at the moment around communication.

We have  done some excellent work over the last year – the trouble is that not a lot of people know what we have done! We need to get much smarter about communicating our efforts and making sure the value of our work is appreciated by a much wider audience. We are in the process of producing a brochure based around EA Services.

We have used the Gartner defined services of Consultancy, Research, Education, Assurance and Modelling. The observant amongst you will note that the initals spell ‘cream’ – which means we become the cream of Devon! Having done a bit of explaining around those headings, we have given a few examples of the work we have done so far. The intention is to have case studies around those to provide a more in depth view of our work.

We have a great communications plan and stakeholder analysis, we now need to put that into action.

As we enter the new financial year, with all the budget constraints that will bring, it is vital that we are seen as an important partner in the business who can help make the organisation better, leaner and more efficient.

Emergent Governance and Enterprise “Business” Architecture

As an Enterprise Architect, you would think that the current financial situation would probably provide the most appropriate climate for Enterprise Architecture – and you would be right. However in the current UK Public Sector context we need to ensure even more than ever that we can consistently demonstrate not just to our managers, but our managers, managers, that we are offering and delivering value across the whole Organisation and across the Enterprise (in local government terms this can include our partners).

The challenge that we face is two fold:

1) Our constant communication and stakeholder engagement challenge – we have plans to communicate and methods for engagement, but we also need to build trust around our deliverables and that is not always in our control, as we don’t provide project/programme management. We do however provide assurance, but we are still developing this alongside the wider governance framework.  It is also not always that easy to simply say that just because we want to encourage and develop re-usable IT components and provide a more agile IT infrastructure and development model that business stakeholders will see you delivering value. These aspects take time and require an Enterprise Architecture programme to be delivered from start to finish. It doesn’t happen overnight, well not in the Public Sector. What the business generally wants is results and not just results but results NOW. They often see more value in project management, although some still think that is a luxury within projects.

The following is an extract from Rik Laurens from CapGemini who outlines this in a much better way that i do.

Projects are managed by projects managers. And good project managers do what they are paid for: reach a predefined target, within time and within budget. It’s good that we have them. And they should stay. But today we are not only interested in a bunch of stove-piped project deliverables anymore. We want re-use of IT assets across projects and we are more than ever interested in project deliverables that are interoperable across the enterprise and beyond and play a role in a broader context. Yes, we still love our project managers that focus on a particular scope and protect that particular scope. But in this era of cloud computing, interoperability, re-use and agility we also need a strong, corporate body that safeguards that the projects are not only doing what is good for the projects themselves but also (or more importantly) do what is good for the enterprise as a whole.

via nterprise Architecture: The Only Way Forward | Capping IT Off | Capgemini

2) We are not always seen as “Enterprise” Architects, mostly we are seen as IT Architects of one kind or the other (we are based within Corporate IT) and that is a boundary that most of the organisation is comfortable with.  This is a big challenge as my role within the team along with a colleague is to develop for the first time an “Enterprise Business Architecture” (EBA).

The EBA challenge is in my opinion a similar one but one which in order to build trust and build some momentum requires a different approach. It is important to acknowledge that we have an agreed Enterprise Architecture programme and have Governance around this but it needs developing and adapting to ensure that it meets the needs of the other architectural effort we are doing. (Information, Technology, Solutions and Business) This is where i believe to help gain some traction and some buy in around “IT people” getting involved in Business issues, we need to find a back door in.

I have thought about this for some time and i’m not sure whether or not it is the right thing to do, but i guess the right thing can only be measured by the type of organisation you work within.

I believe that Governance is the key to unlocking the potential of Enterprise Business Architecture in my organisation and that if we as a team can define, model and deliver a framework of governance that actually supports the over programme. It is worth noting that our Enterprise Architecture team is only 2 years old, so i consider all of what we have done a remarkable success all things considered, but we always want to do more.

The key to governance in my opinion is ensuring that we understand what form of governance we wish to support alongside the type of participation model the culture currently allows. I have posted my thoughts on a Governance Ladder on my personal blog. However in this context we need to ensure that our governance framework is Agile and allows for “Emergent Governance”:

The notion of  emergence, where intelligence is manifested from a collection of minds, is a core concept in chaos theory and the underlying principle in James Surowiecki’s  The Wisdom of Crowds. Scientists have long noted that, on average, the assessments of a crowd are more likely to be correct than the proclamations of an individual expert. From Elisabeth Noelle Neuman’s work on predicting election outcomes ( The Spiral of Silence), to the  central limit theorem that underlies statistical sampling methodology, the emergence of intelligence from large groups has been well established.

The exciting opportunities for governance presented by social networking and collaboration technologies are palpable. The election of a president who understands this potential portents a new golden age for democracy. Perhaps

via Emergent Governance: Who Needs Bees When the Grassroots Swarm the White House

The interesting aspect and similarity i see here is that we have recently undergone some dramatic changes at the top of the organisation. A new Political Administration and a number of our Corporate Management Board retired, this presents opportunities that must be explored and pursued. So with the challenge set out, we now embark on the journey.

Are you risk averse?

Back in the mists of time when I started working in local government, I was assured by experienced staff members that the council was a very risk-averse organisation that wouldn’t take kindly to any fancy new ideas.

Well, I’ve come to realise that nothing could be further from the truth: local government takes enormous risks all the time – they just don’t see them as risks.

So what do we mean by risk? In information security it’s often expressed numerically:

Risk = impact x likelihood

This simple equation tries to capture the essence of the risk decision: if a system has a vulnerability then it may or may not be easy to exploit. If it’s easy to exploit then the “likelihood” number goes up. If the consequences of that are major, the “impact” number goes up. Even if you use a totally arbitrary way to determine these numbers, you still end up with what you want: a prioritised list of risks so you know which ones are the most serious so you can tackle them.

Great. So why do I have a bee in my bonnett about it?

It’s just that we choose to ignore some risks and blow others out of proportion. Software vulnerabilities are well-understood and get a high profile – I’m not complaining about that – but risks in other areas, like the software portfolio or HR policies, are not. So what are these risks?

In the software portfolio, a number of things could happen: the supplier of the software may go out of business, hike licensing or support costs, lose a key member of staff, or decide to retire the software you are using. In HR any new policy carries the risk that a key member of staff might get the hump and leave. There is demographic risk that younger people won’t want to work for you leaving you with a skills shortage in key areas: the economy might take a nosedive (the very thought!) leaving you with drastically reduced budgets.

The possible sources of risk are actually as infinite as the universe. In many organisations it is the IT department that deals with IT-related risks, but what if a reduction in the risk in some IT area (for example a tightening up of policy on, say, removable media) leads to an increase in the risk carried by another area (as workers decide to use Google Wave or a social media platform to share documents instead)? This is known as risk asymettry.

There’s also the risk of doing nothing. Sometimes this is greater than the risk in doing something, even something radical, but our brains are programmed to favour stuff that is familiar so we mentally downgrade the risk of doing nothing: this can lead to some pretty nasty situations. I’ve seen projects and applications carry on many years beyond the point at which they were starting to cause instablity in other parts of organisations, simply because the risk of carrying on as before hadn’t been properly calculated and compared with the risks involved with change.

These issues can only be sensibly resolved if the risks are owned in the right place and practical frameworks are adopted to ensure that as many risks as possible are factored into decision-making. This might sound like a lot of red tape, the nanny state, health and safety gone mad etc etc but actually it’s just common sense. If you put your hand in the fire, it will get burned. If you don’t take it out again, it’ll get burned some more. Oh and by the way, we don’t solve the problem by putting the fire out: you must take your blinking hand out!

Risk-based decision-making doesn’t have to be always favouring the conservative approach. It can liberate you as well by enabling you to take decisions you wouldn’t otherwise have taken because you were afraid of the unknown risk. We recently had a supplier down to talk to us about moving to an open-source model for our software: at first sight this is a major change and fraught with danger and difficulty. But if we understood the risks we were currently running with proprietary software properly, then maybe it would look less risky by comparison (please note: I’m not saying this will happen, it’s just an example).

Thankfully my organisation is moving towards a much more comprehensive view in many of these areas as we implement ISO27000. But many organisations are still stuck in an emotional mindset: you only have to look at the banking system to see what happens when all risks aren’t factored in to decision-making!

I feel that risk is a very powerful concept when it comes to aligning IT decisions with the business because it shares a common language and a common goal. IT must realise the risks that it loads onto the rest of the business by making changes (sometimes very minor ones) – but the business must also step up and own all the risks (including the IT ones) in their respective service areas. This forces realistic IT decisions to be made as it becomes clear that risk cannot be outsourced, and procurement, training and whole lifecycle costs naturally get a higher profile in decision-making than before.

EA styles 3: transforming the strategic paradigm

I’ve briefly covered how an EA team might *react* when faced with a particular dominant strategy formation style in an organisation in some previous posts .

This isn’t good enough for me though: I want it all and I want it to be the way I want it!

So if a particular strategy formation paradigm isn’t to your taste as an EA, what can you do about it? Is there a “preferred style” that EAs should always aspire to on behalf of their organisations? Is this even ethical?

Complex questions, and no clear answers. It may be that an EA team will see trends coming that they feel will negatively impact their organisation if the strategic paradigm isn’t changed. That’s good. But if the EA team aren’t the ones taking the risks in the organisation (for example, putting up the money!), perhaps they don’t have any business making senior management change their approach by fair means or foul.

I think that EAs will always have well thought-out views on the way organisations make strategic decisions – it goes with the job. Each EA will have to decide if and how they agitate for change dependent on their own values and with a mind to their own positions (especially in political organisations). So with that massive caveat, let’s look at the tools EAs have for making changes to strategy formation, based around the services that EA teams provide.

– Architecture Creation: an EA team can create architectural models that emphasise the sovereignty of a particular group or population in the organisation. Such a model could, over a long period of time, transfer decision-making power to different groups and thereby influence the strategy style. This probably comes under the category of “EA black ops” though and is vulnerable to existing powerful stakeholders pulling the plug on the EA team

– EA consulting: can promote particular styles of project delivery, and in the process embed particular ways of thinking in to the organisation

– EA compliance: can block or alter the course of projects that don’t echo the EA team’s preferred style.

– EA communication: this is the biggest way that EAs influence the organisation as a whole. It may be difficult to get into conversations with key stakeholders, however, if the organisation is very hierarchical and EAs will need to use their contacts to leverage themselves into conversations

– EA research: this is where EAs can do the ethical thing by bringing the trends that effect strategy creation styles to the attention of the people who can change them (not always senior management).

Change is always difficult: persuading powerful people that they need to personally change is even more hazardous. Building a momentum and sense of urgency behind the change is therefore always going to be important.

EA Styles 2: Services

In my last post I put forward the idea that the way an EA operation goes about its business might differ according to the sort of decision-making structures that are routinely used in an organisation.

I need to apologise for the length of that post and the occasional shorthand that crept in whilst I attempted to condense a large amount of information into something blog-sized: I totally fail at plain English!

In an attempt to rectify that somewhat, in this (also quite long) post I’d like to show how this theory might actually deliver some value. To do this I will leverage a post by Gartner’s Bruce Robertson where he describes an EA effort as a set of services that it provides to a business. To summarise Bruce’s post somewhat, these services are:

  • EA creation (development of organisational and architectural models to help unify strategic and IT planning)
  • EA consulting (where an EA adds value to a project by helping it align itself with strategy and future trends)
  • EA compliance (where a project is assessed for its fit with the organisation’s future direction, strategy, infrastructure and referred or accepted)
  • EA communication (where EAs insert themselves into the conversations that happen around the organisation, educate, inform, listen and adapt)
  • EA research (looking at new trends, new technology, industry analysis etc)

To illustrate how the concept of an EA style might be applied in the real world, let’s consider 2 extreme examples: a small owner-managed retail outlet and a medium-sized public sector organisation (oooh, like a council maybe).

Firstly lets look at how strategy is formed in these two organisations. In the small business, the owner will make all the decisions. She is an entrepreneur with a vision that caused her to start the business: she knows what she wants (but might change her mind if she gets new information): objectives will be in terms of sales and business growth. In the council, on the other hand, strategic direction is broadly set by politicians who are elected every 4 years: there is a hierarchical structure: central government makes statutory demands: audit and transparency are required.

The former, then, is an entrepreneurial business and demands an entrepreneurial style. The EA (probably in this case either the owner herself or an external consultant) needs to plug in to the vision and realise it quickly: management information from POS systems, staffing levels and training, marketing research processes are all needed.

  • EA models will be simple and amount to a description of the various processes required
  • EA consulting will be about challenging the owner’s vision, acting as a “critical friend”
  • EA compliance will be about ensuring that new initiatives (like diversifying product range or opening another outlet) are consistent with the vision
  • EA communication will be about networking with other entrepreneurs to see if synergies can be created, marketing the business informally and educating the entrepreneur about the risks she might be getting exposed to
  • EA research will involve looking at trends in the sector to see if anything is coming up that might change or disrupt the business model or create new opportunities.

All these processes will happen informally, sometimes all at once.  There will be few reports written, diagrams drawn, or software tools used.

The public sector organisation, by contrast, is fundamentally political. Direction is set by elected politicians and this creates a cultural background that the organisation has to work with. Political fashions change: one ruling party might be focussed on making investments for particular social or economic outcomes, while another might be more focussed on shrinking the organisation scope and cutting costs.

In this kind of organisation, a team will not survive if it doesn’t manage its stakeholders. A brilliant team that doesn’t do what the most powerful people want is doomed – regardless of how brilliant it is or how hard it works. So the EA team need to gain traction by identifying the most powerful stakeholders and finding out (sometimes indirectly) what their priorities are and finding ways to deliver them:

  • EA models will be just detailed enough to describe the area of stakeholder concern
  • EA consulting will challenge projects to deliver the top priorities
  • EA compliance will focus on rooting out those projects that work against the main stakeholder priorities
  • EA communication will be the biggest part of the job, trying to understand the currents of influence that run through the organisation so that the team can flow with them
  • EA research will look at new ways these priorities can be delivered

Although these are very different types of organisations, with different approaches, in both cases the EA team acts as a facilitator for the usual strategy formation process.

Sometimes, though, we might want to change that. But that’s another topic.

EA Styles

Back in August a number of posts appeared in the blogosphere following Gartner’s press release encouraging the use of “emergent architecture”. The debate is nicely summarised here (http://www.biske.com/blog/?p=670) by Todd Biske.

The language that Gartner used, however, rang some bells with me: in my recent studies I looked at the various schools of corporate strategy making as defined by Henry Mintzberg (nicely summarised at http://www.12manage.com/methods_mintzberg_ten_schools_of_thought.html ): Mintzberg obviously had his own favourites, but nevertheless had tried to describe the various ways that strategy *could* (not necessarily should!) be formed in an organisation.

Organisations obviously come in all shapes and sizes. Some have strategy formation processes that go back a long way or are dictated by their constitutions or remits: an army will always require a certain amount of disciplined, top-down formal strategy creation compared to a web 2.0 startup with 3 people, which needs to react quickly to change strategy if something new and game-changing appears on the market. Government agencies will always be answerable to politicians and will need to change strategy every electoral period to suit the new administration. Publicly listed companies need to drive shareholder value and adopt a strategy creation process that will suit their goals, depending on which sector they are in.

So what does this mean for an enteprise architect? Perhaps the EA effort needs to initially align and then seek to transform strategy creation processes in its organisation?

Mintzberg defined 10 “schools” of strategy formation in total. I’ve listed them below and spent a grand total of 10 minutes considering what form the EA effort might take in each case.

Design

  • Deliberate strategy creation as a process of conception. Match the internal situation of the organisation with external factors.
  • Use tools like SWOT analysis, Ashridge Model
  • Planned
  • EA must: use a “Classic” Gartner approach, based around CRV and creating strategic solutions: TOGAF

Planning

  • Deliberate strategy creation as a formal process. Separate planning teams create strategy and use a pre-defined execution methodology.
  • Scenario Planning: Parenting Styles
  • Planned
  • EA must: use Zachman approach coupled with strong project management methodology (eg Prince2, MSP): TOGAF

Positioning

  • Deliberate strategy creation as an analytical process. Positioning of organisation within industry or market.
  • 5 forces: value chains: BCG matrix: game theory
  • Planned
  • EA must: use Heuristic approach utilising reference models, eg MIT EAS approach: TOGAF

Entrepreneurial

  • Semi-deliberate strategy formation as a visionary process. CEO is architect of the strategy.
  • Emphasises intuition, judgement, vision, leadership styles
  • Semi-planned
  • EA must: Inform and deliver the CEO vision: challenge, support, and then formally design and programme manage: TOGAF and heuristic tools

Cognitive

  • Strategy creation as a mental process. Maps, schemas, concepts and viewpoints.
  • Groupthink: MBTI: Johari Window: Cognitive bias
  • Emergent
  • EA must: Support cognitive processes across the organisation and making them real

Learning

  • Strategy creation as an emergent process. What works and what doesn’t gets incorporated over time in a series of small steps.
  • Organisational Learning: Knowedge Management: SECI model
  • Emergent
  • EA must: Provide a set of standards that the strategy can use as a platform for its learning. IFAPS.

Power

  • Strategy creation as a process of negotiation.
  • Stakeholder analysis: force-field analysis: stakeholder mapping
  • Emergent
  • EA must: Identify powerful stakeholders and realise their common visions.

Cultural

  • Strategy creation as a collective process, as a reflection of the organisational culture.
  • Cultural Intelligence: Ashridge Mission model
  • Emergent
  • EA must: Define dominant values, design and build social networks, and critically appraise the corporate culture

Environmental

  • Strategy creation as a reactive process. Sees the environment as the dominant factor in determining strategic direction.
  • Contingency theory: situational leadership
  • Emergent
  • EA must: Design and build solutions to give the organisation more options in the expected future environment

Configuration

  • Strategy creation as a transformational process.  Organisations change structure as strategy changes.  Manage stability and discontinuous change without too much disruption.
  • Organisational configurations: chaos theory: catastrophe theory: disruptive innovation
  • Planned / Emergent
  • EA must: Propose and design valid alternative configurations (for discontinuous change) and systems of  continuous improvement (for stable phases)

Interested to maybe develop this further: what sort of strategy creation style is prevalent in your organisation?

Just wondering

What are we?

We are Enterprise Architects, thinkers, dreamers, intelligence gatherers, visionaries, police, communicators, persuaders, presenters, sharers, writers, budget planners, strategists, principled … Is there any wonder we find it hard to explain who we are and what we do! 🙂

Communicate, communicate, communicate

That’s the message we are getting about EA in general – we need to communicate better! To that end, we have spent two days together this week looking at all things “communication”.

It’s been a good two days, we have worked on who we are, what we are, stakeholders and key messages – we even have a new tag line – as shown above. I hope you like it!

Trying to put all we have talked about into practice is going to be a challenge for all of us, but we like a challenge!

EA: It’s all about communications

After sitting in one of our focus groups yesterday afternoon (and getting a thoroughly “realistic” assessment of ICT from the perspective of some of our customers!) I am reflecting on the added value that an EA programme is likely to bring to people on the ground, who are struggling to deliver vital services to citizens. Whether those final customers are road travellers, schoolchildren, vulnerable adults or even tourists it can sometimes be difficult to join up and communicate the value that someting quite abstract like an enterprise technical architecture can give them!

Our last ICT strategy essentially gave management the mandate to set up an EA team as a mechanism for making IT a full business partner to our directorate customers. Of course, it takes two to tango, and I have to ask if our directorates want, need, or are even ready for such a partnership. This emphasises communications processes in building the relationships, and indeed Gartner recommend the creation of a communications plan and to create a stakeholder management strategy which grows as the relationship with the business develops.

As this story unfolds I also am coming (slowly – I’m not the sharpest tool in the box sometimes!) to the conclusion that the Gartner architecture process that I diagrammed in my first blog post here is not just designed to deliver an accurate new set of architectural models (and therefore better ICT) but is also designed such that, if followed along with the communications plan and proper stakeholder management, to engage the right bits of the business at the right times.

In fact I now believe that, in making ICT a full partner to the business, the EA process is ENTIRELY about communications. Our EA methodology is a sideshow in this process, which is the story of our relationship with the key players in the business and how that can engender a new understanding in the business of a different way to plan its ICT investments and strategy as well as drastically realign ICT’s understanding of the key priorities in the business and how they are going to deliver them.

Of course we have technical skills, strategic principles, and models – and these are the things we bring to conversations. But the point of the conversations is to educate, to build bridges, to raise understanding on all sides – the better ICT is a result of the better relationship, not the end in itself. If the relationship goes, so does the planning!

Looked at from this point of view, if we sometimes struggle it’s because we don’t make the communication the central plank in our approach. And this also means that we need better skills (I certainly do!!) in communication, influencing, politics, assertiveness, tact, diplomacy, and charm – not skills traditionally associated with an ICT department. Gartner say that most EA programmes fail because they don’t “do the comms” properly – a particular tendency with fundamentally technical people – but I now want to take it a stage further and say that EA programmes fail if they do not put the communications aspects front and centre.