Zachman Framework != Enterprise Architecture

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.

 

What characterises a service?

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.

 

CIO podcast from MWD with Peter Burggraaff

Here is the audio of what we hope will be a series of podcasts with CIOs who’ve instigated work to improve IT-business alignment in their organisations. The interview is between us two Neils (me and Macehiter) and New Zealand-resident Peter Burggraaff, until recently the CIO of NZ retail chain Farmers Trading Company. Peter talks to us in this 31′34″ podcast episode about his initiative at Farmers and the outcomes he achieved.

In the podcast Peter explains that Farmers was in a situation where IT cost was way too high, and although the IT organisation was doing some things well (particularly managing operational services) it wasn’t seen as a real contributor of business value as Farmers looked to put some big business changes in place. He goes on to explain how he started to turn this situation around and built a solid and trusted relationship with Farmers business management. Thanks Peter!

If you’d like to get involved in this programme of podcasts don’t hesitate to let us know.

 

Two interesting insights on enterprise architecture

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”?

 

The rising importance of the enterprise architecture

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.

 

Great blog: Beyond Blinking Lights and Acronyms

Beyond Blinking Lights and Acronyms is a consistently thought-provoking blog from “currently resting” CIO Mike Schaffner. In this entry he calls out a recent CIO.com piece which looks at the challenge of trying to run an IT capability when individual business groups also have their own separate IT teams. Mike calls this “Shadow IT“.

The key to resolving this challenge, as we explain in the book, is to first accept reality – as a CIO or IT Director in the 21st Century you cannot, and will never be able to, control all IT activity that goes on within your organisation. Once you accept that, you can start to work with business teams and their own IT groups to build trust and influence. The critical thing to get right is that you have to be able to pick your battles – to know what’s really important to put effort into standardising across an organisation, and also to know where you should adopt a more relaxed approach.

 

Start ‘em young

Another of the sessions at the Architects Council was a workshop held between members of academia and the council members (largely from industry), to report on last year’s “Developing the Future” initiative, and to discuss the quality of people coming into the UK IT industry and how it could be improved. This was a hugely valid, and valuable discussion – particularly in the context of IT/business alignment. Undoubtedly there will be issues in other countries, but there does seem to be a dearth of high-quality post-graduate trainees in the UK, that really “get” what IT is for – to the extent that UK companies are looking abroad for skilled staff not just because people are cheaper, but because, quite simply, they are seen as better.

The mind map below shows the outcomes of the discussions, in terms of both the challenges and the resulting requirements. I thought the school system came in for a lot of stick, which was unfortunate as (or perhaps it was because) there was nobody in the room to defend it!

 

IT-business alignment at Credit Suisse

McKinsey has a very interesting interview (free subscription required) with Tom Sanzone, the CIO at Credit Suisse where he describes his approach to IT-business alignment. There are a number of points he raises which resonate well with the principles we outline in the book.

He makes it very clear that a IT and business need to collaborate as peers, rather than as supplier and customer:

Many CEOs talk about how crucial technology is to the future of the company, but then they place IT two or three layers below them in the organization. I think if something’s that important, you want to keep it close. I’ve always felt that if companies are truly technology-centric, IT needs to have a seat at the table …If we can create a competitive advantage in delivering our IT products to our internal customers, we’ve done our job. It’s then up to them to go out and sell and trade and do business. That’s the partnership.

Credit Suisse has an ambitious strategy to integrate its three core businesses – private banking, investment banking and asset management. The IT organisation has a key role to play in enabling that integration, whilst allowing each business to become a leader in its own right. Sanzone explains how this requires coordination of goals and objectives and a portfolio-based approach:

So there’s a whole portfolio of initiatives within technology to improve profitability, grow revenues, and improve processes.

He also highlights the importance of running IT within the business and establishing the right organisational structure and roles to facilitate engagement:

One of the things I did early on was to ensure that IT was closely linked to the business. Just as I sit on the executive board and work for the CEO, I made sure each business’s CIO also sits on the management team of the relevant business.

These are just a few snippets of particular relevance to The Technolgy Garden but the whole interview is worth reading, not least for Sanzone’s insights on the management of innovation.

 

Effective IT Summit 2007 story: 3PI

Paul Coby, CIO at British Airways kicked off the 2nd day of the conference, discussing IT-enabled business transformation at the airline. He was both engaging and honest (taking comments about lost baggage and queues at the online check-in bag drop on the chin).

He outlined how BA set itself some ambitious transformational targets, – 100% e-tickets, 50% customer self-service – and the role of IT in attaining them. The targets were deliberately high (almost to the point of being unachievable) for two good reasons: first to get the attention of the business and second because of the tendency to do just enough to reach targets. There are four “golden” rules that apply to the IT initiatives that support this transformation:

• Simple and compelling customer propositions
• Design processes for use by the customer
• Do it right first time
• A single solution across all departments

These rules, he believes, are key to turning IT architecture into business strategy. When discussing the last point he raised an issue which we address in the book: the difficulty of getting different business units and departments to pull in the same direction given that they are each focused with laser-like precision on the operations within their own domain. That’s why its so critical for organisations to work towards coordinated goals and objectives, something which BA’s “golden” rules capture – albeit at a high level.

Paul also discussed the organisational structure he established within IT to support transformation: global IT operations; delivery of new IT capabilities; and IT planning and business change. The IT planning and business change organisation is where the 3PI of the title comes in. It’s the approach followed when evaluating new IT initiaitives:

• Proposition – review the proposed initiative in light of other proposals
• Process – understand the end-to-end business process (not the shadow that IT casts on that business process)
• People – consider usability and training
• IT – finally there’s the technology

In the book we discuss an IT Governance Board process, which covers similar ground to 3PI and focusses on gaining consensus across the organisation (which is also key to adherance with BA’s fourth “golden” rules). We also highlight the pivotal role that business process plays in the establishment of a common language as part of an enterprise architecture process.

Whilst Paul’s presentation made me feel a little more comfortable about the advice we are providing in The Technology Garden, he had a few things to say about the IT market which will leave some feeling a little less comfortable. When it comes to what’s hot and exciting, he called out Google, eBay, iTunes, Skype, Wikipedia and India. What’s not: big hardware, software and consultancy suppliers!

 

Effective IT Summit 2007 story: Positioning IT to deliver business innovation

I spent the last couple of days in Cardiff at the Effective IT Summit 2007, courtesy of Information Age, which featured an interesting mix of future gazing and the current realities of IT in business. Myron Hrycyk, CIO at NYK Logistics (a 17,000 employee, $3.3B logistics provider) gave a very informative presentation describing the approach he took to position IT as an enabler of business innovation at his previous employer (and which he hopes to follow at NYK).

In summary, he outlined four stages:

• Achieve operational excellence
• Credible project delivery
• Strategic alignment
• Business innovation

The nomenclature may be different but the objectives of each of these stages and the principles and disciplines which underpin them have a lot in common with the six principles and the roadmap we outline in the book. For example, Myron highlighted the importance of IT process improvement (in his case through ITIL), a common language, management of IT initiatives as a business-driven portfolio and effective relationships with strategic suppliers.

As well as the strong synergies with our thinking, there were a couple of other things I found particularly interesting. The organisation in question was heavily influenced by Japanese management techniques. So, for example, Six Sigma practices were followed; crticial problem solving techniques and communication cells (groups of employees focussed on particular tasks) focussed on resolving issues; strategic planning involved policy deployment techniques. Myron recognised that applying similar techniques to the way that IT operated would be an important part of establishing a common language so, for example, IT planning used the same policy deployment techniques.

The other fascinating insight concerned the “innovation process”. Like NYK, Myron’s previous employers was a logistics provider and they used a model of the supply chain to identify opportunities for IT-enabled business innovation. They modeled the supply chain – what’s so fascinating about that? It’s the fact that it was a physical model with warehouses, trucks etc etc and one, moreover, which was owned by the business not IT.

The presentation concluded with 9 recommendations

• Get day to day operations running properly
• Take to the business in the same language
• Credibly deliver projects
• Organisationally align to the business
• Break down the barriers between business and IT
• Find ways for IT to be proactive
• Take a business view
• Align IT to business strategy and objectives
• Create and foster IT-driven business innovation

which are not a million miles away from the principles we derived from interviewing Myron’s peers across a range of industries, from financial services to public sector.