artITecture

who makes architectural decisions and a TOGAF rebellion June 30, 2011

so i am a fan of the idea of architectural decisions – an architectural decision is the consideration of a problem which needs a soltion (most likely an it solution) and deciding and agreeing what to do

In my opinion, solving problems like this is the very essence of why architects exist because these problems do not often have obvious answers and there are multiple options to solving any particular given problem.

In the last month or so at work I have been looking at who decides which applications are strategic and which are not

I assumed this was a decision the Enterprise Architects made

Much to my suprise in over half of my organisation this decision is not made by people who call themselves architects at all. Instead this decision is owned by IT staff who have come from the business and now are in IT, and by Application Portfolio Managers / Application Managers.

Application Portfolio Management is a role not oft spoken of in the realms of architects but one everyone should be aware of. Application Managers typically own the operational running of a set of applications i.e. incidents, the projects, the cost and customer satisfaction of those applications. This this usually means they talk to the business very frequently about outages, incidents, projects, etc

Therefore adding on an accountability to determine whether an application is strategic or not is a very nature addition to this role. This is probably in consultation with architects but ultimately takes this decision away from the architect, if they every owned it in the first place

I have found this answer rather challenging

I had an assumption that architects would normally own this decision. They are typically technical experts with depth in one or more business domains. The most logical home for this decision

However, on reflection placing the accountability with an APM seems like a more natural home.
- they have a more holistic view of the application, its operational issues, projects in flight, customer satisfaction, cost
- they probably control the project and operational budget and can more easily make a more realistic determination about the ability of the organisation to make an investment or replacement of an existing application
- they do not need deep expertise, they can call on other expertise, most likely architects, to help with the decision but ultimately as the owner of a portfolio are the people who will have to deliver it. This gives a very healthy dose of reality and objectivity

if i put the TOGAF crop circle in front of an application manager, would they have the faintest clue what i was showing them or talking about?

the answer is almost certainly no

if i put the TOGAF crop circle in front of a business person, would they have the faintest clue what i was showing them or talking about?

absolutely not

so a togaf rebellion…

if I changed TOGAF to about analysis of requirements, design options, costs, benefits, value, implementation time, functionality, usability, and risks would they know what i was talking about?

yes they would

and so i am concluding that TOGAF is a method designed for architects by architects using an abstract and inaccessible language useful only to architects

in my opinion a new method is needed which business people can understand. They can understand that there are specific considerations to determining whether one IT solution versus another is better or not

im afraid terminology like Architecture contract, preliminary phase, and migration planning will never be part of a discussion with the business which i ever have

and perhaps thats why application managers are better placed to have accountability for architectural decisions than architects

is anyone interested in creating a method like the one i suggest, i cannot do it alone…