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