EA


This comes from Leo de Sousa, an EA in Australian Higher Education who asked the Shared Insights EA Network to provide ideas about what EA trends they were seeing.

My take: leading organisations get EA and are figuring out how to link it to other important IT governance-related practices, but this is still a sparse community with demand for skills outstripping supply and not enough consistent “good practice” guidance out there. Grass-roots communities (like the aforementioned EA Network) are starting to help EA practitioners build a critical mass of “stuff that works”, though.

If I had any more time, I’d think about writing a followup to The Technology Garden, focused specifically on Enterprise Architecture practice in the real world…

Advertisements

James Tarbell has this great post, responding to one of the people we’ve interviewed in our research, James McGovern. James T calls out some very insightful similarities between architects and gardeners.

My favourite: “You can get hung up on understanding the big latin words/technical terms or focus on requirements to achieve a result”.

In this post Andrew McAfee at Harvard Business School has a detailed discussion about the impact of IT. He concludes with the following question:

What’s the correct way to think about IT’s effects going forward: diminished competitive significance because the technology innovations are being absorbed, or sustained significance because IT has moved industries into permanently higher rates of process innovation and replication?

Our research for the book provides strong evidence for the latter and that’s ultimately why we set out to write it in the first place.

Once the IT organisation has got its own house in order and gained the trust of the business, the route to effective IT-business alignment – understand and reflect the business; engage the business; and drive the business – and the enterprise architecture process that supports it is all about harnessing IT capabilities (people, technologies and practices) to support process innovation. That’s why, as we explain, the concept of business processes offers the most appropriate basis for analysing business activities and informing technology, investment and sourcing decisions.

I was talking earlier on to one of the people we interviewed for the book, outlining the main findings and getting some feedback. One of the main topics we focused on was the nature of Enterprise Architecture, and what characterises EA work “done right”.

The person I was talking to relayed a conversation they had with a client recently that was interested in becoming “Zachman compliant”. The client was under the impression that if they could do this, it would be a stamp of approval that they were “doing EA well”.

I’ve seen things like this myself from time to time, and it’s worrying. Organisations set up EA teams that are naturally inclined to focus on modelling technology landscapes and so on, and that focus more on the outputs (models) than on how they arrive at those outputs.

The problem here is that the process of EA is at least as important as the outputs. “EA done right” is as much about how you conduct EA work, as it is about what you produce. EA done right involves architects engaging in truly two-way discussions with stakeholders in IT and business – sharing ideas, learning and also communicating what’s been learned so far, so everyone understands more. EA done wrong involves architects sucking ideas from the brains of “users” and not giving anything back. The architects learn more but very quickly you end up with a fundamental disconnection between business and IT and you’re no closer to developing a common language.

And this brings us back to Zachman – because although ZIFA goes further than just promoting the Zachman framework (it’s starting to promote the importance of developing a good process) there are an awful lot of people out there who just focus on the framework. And although the framework is  a great way of categorizing models and knowledge, it says nothing about how that knowledge is arrived at.

If you just focus on getting good at filling in the cells in the Zachman framework, that’s no guarantee at all you will be doing EA in a way that helps IT or the business.

A couple of weeks ago I was party to another event, this time hosted by IBM. At short notice I was asked to facilitate a session on defining services, which was interesting in the extreme as it very quickly became clear in the earlier sessions that there was no clear definition of what a service was – particularly as there were two types of people in the room – business analysts and technical architects.

So, I decided to take a different tack. Rather than trying to fix a definition of service, I thought we would go round the room and ask what characterised a “good” service. Here’s what we came up with:

• Value – the benefits of accessing a service should outweigh its costs
• Reusability – it should be possible to access the service repeatedly, with the same level of interaction and service quality
• Meaningfulness – it should be possible to describe the service in clear, relevant terms
• Autonomy – the service should be cohesive, i.e. clearly bounded
• Independence – the service should also minimise dependencies with other services
• Contract – the service should offer its own guarantees in terms of what it delivers, and how: such terms should be subject to prior acceptance by the service user.
• Uniqueness – the service should minimise overlaps with other services

With hindsight, there is possibly some honing that could be done with the above list – the difference between “Autonomy” and “Independence” for example, is not all that clear. What was interesting however, was that even as the debate raged around what a service should look like, there was relatively little controversy about what separated the wheat from the chaff. For organisations looking to develop their own service strategies, this would appear to be a good place to start.

Nick Malik (who we interviewed for the book) and Michael Platt, who are both coincidentally from Microsoft, have recently posted some thoughts on enterprise architecture, which align well with our research into the topic for the book.

First to Nick, who discusses the extent to which stakeholders understand the value of EA. You should read the whole thing but I wanted to call out this:

Some may feel that the value of architecture is to design the solutions that the company needs to consume (build the solutions right!). The real value, in my mind, is to help make sure that the money spent on IT is building agility and not complexity (build the right solutions).

I cannot emphasize this enough, and as we share the message with our friends and collegues, we need to be clear about this point.

Enterprise Architecture is not about “building solutions right”

Enterprise Architecture is about “building the right solutions”

Absolutely! EA is first and foremost about understanding the business, as he goes on to point out:

The real value for IT is in providing strategic information, opportunities, and success to the company as a whole. That means that IT figures out what projects need to be worked on, in partnership with the business. IT works not as a servant but as a knowledgable and capable business partner, suggesting business opportunities that the business may not have thought of, and taking it to the business and executive management for funding.

Which leads me on too Michael’s post commenting on a paper assessing the applicability of existing EA frameworks (Zachman, TOGAF et al) to two common scenarios:

a company which had a fixed and inflexible set of stovepiped application that were stopping progress (IT is a problem scenario) and a company that wanted to expand its business using IT (IT is an enabler).

The upshot of the paper is that the existing EA frameworks didn’t really address either scenario, which is interesting in its own right. However, what resonated with me particularly in the light of Nick’s post was Michael’s comment (and he may be overstating the case) on why in the second scenario:

In the “IT is an enabler” scenario none of the EA methodologies even started to look at what the company wanted to archive [achieve] and so failed at the first post.

If enterprise architecture processes and teams aren’t considering what the organisation is trying to achieve, how can they move beyond “building solutions right” to “building the right solutions”?

CIO Magazine has an interesting article on the role of the enterprise architect, which highlights a number of aspects of EA which we call out in the book, including:

  • The importance of communication and collaboration – in our opinion, the value of enterprise architecture is as much about process of getting to the “as is” and “to be” architecture as it is about those outputs. Enterprise architects should not just be exporting, as well as importing, information and insights
  • Enterprise architecture is a process – historically, too much emphasis has been placed on enterprise architecture outputs at the expense of the processes, policies and procedures that create those outputs
  • Enterprise architecture should focus on generating consensus – individual business groups are, quite rightly, focussed on their own operations; enterprise architects should be looking across the organisation (and beyond its boundaries) to identify shared goals and objectives
  • Enterprise architects must balance short-terms needs with long-term strategic objectives – as the chief enterprise architect at Toyota Europe points out the enterprise architect “must understand the business strategy and translate this into an architectural approach (macro view), but he [sic] must also be able to work with individual projects and deliver very concrete guidance to these projects that focuses on the successful delivery of the individual project within that macro view

The article (like our book) includes some valuable insight from practitioners and is worth a read. There’s also an interesting discussion on certification from the likes of the Open Group.