Relating IT and Enterprise Architecture

IT Architects have a hard time.  It’s commonly perceived that the IT department is slow to deliver the whole solution, can’t keep up with the business and is too expensive.  In any solution discussion, there always seem to be a lot of IT architects, each espousing a different technology as the ‘silver bullet’ and often disagreeing with each other to the point of religious fervour.  Passionate yes, and misguided – maybe.

Those IT department traits, I believe, are symptoms of the stage at which IT Architects are included in any business discussion, but I’m not advocating bringing them in earlier either !  In the recent conversations about whether CIOs should be given a seat on the board, my position was that they should and deservedly so.  What I got wrong was what would happen next: CIOs  briefed their IT architects on the overall business strategy and the IT architects bullishly defined what was needed to deliver the strategy.  However, alongside the CIO on the board, were the other directors that ran operational departments and they needed to define their departmental strategy.  What happened next should have been predicted: when those operational directors went to IT to ask for support in developing their ideas, they were told that IT already had the answers.  When both solutions are analysed independently, IT had ignored business critical issues in developing their solutions and the business hadn’t (had the chance) to address IT concerns.  So what I got wrong in my support for CIOs joining the board, was that IT now viewed themselves as being the way to deliver strategy, rather than a supporting actor.

I have witnessed discussions in which an IT architect sets out how the business needs to change to accomodate a new peice of IT that’s the silver bullet to delivering the business strategy.  Those meetings never go well but there had clearly been hours of expensive IT architecture work put into the definition, so much so that the operational directors often wondered why those architects weren’t dealing with customer issues.  All of that IT architecture ignored one fundamental fact: IT don’t run the business and often don’t have the best view of how to move the business forward.  It’s also true that, all too often, IT architects want new technology, rather than improving what already exists or, heaven forbit, admitting that their last bright idea didn’t deliver the business benefits that were promised.

So what are IT architects responsible for ?  My list would be:

  • defining the the lifecycle for each of the applications and providing that information into as an ‘influence’; 
  • developing ideas on how to reduce the TCO for IT platforms;
  • defining IT principles, by decomposing the business vision;
  • setting IT standards;
  • governing the IT aspects of solution architectures; and
  • delivering IT solutions, hand-in-glove with the appropriate business unit.

However, in all other discussions on how strategy can be implemented, IT architecture should to defer to the business units and explain the impact of IT principals to the business units.  For example, moving to a cloud-based implementation model might form part of a principal. However, the move to cloud has an implication on how IT is paid for (i.e. OPEX vs CAPEX) so that too should be fed into the enterprise motivation model as an influence.

That approach ensures that IT Architects speak on the subject on which they are most knowledgeable – IT.  That IT Architecture is a specific activity in the TOGAF model for a reason – it takes knowledge of the existing IT landscape and knowledge of new technologies.  There are many IT Architects that understand the application landscape across the whole enterprise and they’re often called ‘Enterprise Architects’ which is a confusing term.  I believe that the Enterprise Architects perform their activity, in TOGAF terms, in the Vision and Opportunities and Solutions activities and then lead on through the rest of the ADM activities.

So when should IT architects ben involved ?  In my view, the ‘proper’ sequence of events, after strategy has been developed, is for the Enterprise Architects (EAs) to help the business executives develop the strategy to the next level of detail and update roadmaps documentation as appropriate.  The EAs develop a new ‘to-be’ operating model and communicate with the various architect specialisms on how that new operating model can be realised and then gain agreement on the order in which change should be implemented: essentially ‘Agile architecture’ or my definition of it anyway.  If an incremental enhancement requires a complete refit of IT platforms then the discussion becomes one of cost/benefit analysis, not one of who is best placed to refine strategy.