Don’t forget your stick of rock…

In 2013 I wrote a small article for a publication around IT architecture, which was designed to give a brief overview of its function and worth to those unfamiliar with the discipline; unfortunately, it did not make it to print at that time.

For those of you who don’t want to go hunting through LinkedIn for it, I’ve reproduced it here.




“Time is money”; an old adage but one that has never been more relevant than in today’s fast-moving world. Our global, ‘always online’ culture means businesses and organisations must be able to serve consumers 24-7-365, often requiring considerable on-going IT spend to meet these demands.

Yet, the high-profile stories of large IT projects running over-time, over-budget and missing the defined objectives are commonplace. For example, the McKinsey/Oxford Study [1] concluded that ‘on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted’.

So how does this happen? What problems cause so many large IT projects to encounter issues? Overall, there are many factors that can affect an IT project over its lifecycle; the key ‘Project Impaired Factors’ highlighted in The Standish Group’s ‘Chaos Report (1995)’ [2] included aspects such as:

  • Incomplete requirements (ranked 1st)
  • Lack of user involvement (ranked 2nd)
  • Unrealistic expectations (ranked 4th)
  • Lack of Executive support (ranked 5th)
  • Changing requirements and specifications (ranked 6th)

More recent reports from major IT organisations such as Oracle [3] and IBM [4] cite similar issues; these ‘problems’ are not new and are still not being sufficiently addressed.

Solving such challenges within IT projects does not lie with a single business area, process or individual. Alongside sound IT project management there is another vital (and sometimes overlooked) function which can reach across an organisation; IT architecture.


One could be forgiven for believing the word ‘architecture’ relates only to the world of construction; a term for the conceptual and logical designs that define a building, from the amphitheatres of old to the most modern skyscrapers in capital cities across the globe. However, the world of IT has its own definitions for ‘architecture’ and the concepts it encompasses are equally fundamental.

‘IT architecture’ is a broad term, so much so that Gartner (the world renowned IT research and advisory organisation) have two definitions for it (abridged here):

  • The overall design of a computing system and the logical and physical inter-relationships between its components
  • A framework and set of guidelines to build new systems; a series of principles, guidelines or rules used by an enterprise to direct the process of acquiring, building, modifying and interfacing IT resources throughout the enterprise

Going deeper, the most common architecture disciplines are:

  • Enterprise Architecture – strategic, holistic, business-focused analysis of policies, processes and technologies to define future state and effect change in order to realise business vision and goals. Often seeds Solution Architecture activity.
  • Solution Architecture – definition of a specific solution end-to-end based on requirements from various viewpoints, e.g. business (functional), technical (non-functional).
  • Infrastructure / Technical Architecture – responsible for defining the physical IT infrastructure which hosts or facilitates an end-to-end solution, e.g. servers, network equipment, etc.
  • Data Architecture – the models, standards, policies and rules which define the parameters of information existence within an organization, e.g. collection, storage, use and structure.
  • Information Architecture – the framework for identifying, classifying and organising data within a focus on use; not limited to the actual data itself, Information Architecture will often categorise channels of presentation also, e.g. digital content, written or printed media, etc.
  • Security Architecture – the definition of security controls and countermeasures to protect the organizational systems and data, including physical security where necessary. Highly integrated with overall information security.


The largest parallel with traditional construction architecture can be drawn here; if a building is designed badly, it will be compromised in either form or function. In the worst case, it will be structurally unsound and run the risk of collapse. The same is true for IT solutions.

Any significant IT change requires a thorough understanding of an organisation’s ‘As Is’ and ‘To Be’ states, with the end-to-end IT detail of those states being a core architectural focus.

IT architecture must to be engaged from the inception of any IT project and in the case of Enterprise Architecture, there is arguably engagement prior to that through close and enduring alignment with the business.

Modern IT architecture frameworks, such as Zachman [5] and TOGAF [6], are designed to meet the scale and complexities of today’s IT projects. Attention within such methodologies, and indeed any sound IT architectural practice, is not paid solely to technology; financial considerations such as Total Cost of Ownership (TCO) and Return On Investment (ROI), risk management, efficient and repeatable processes and effective engagement of stakeholders throughout a project are all of equal, if not greater importance.

IT architecture activities do add time and cost to a project and this is often seen in a negative light by stakeholders. If the business knows what it wants and the funds to attain it, why can’t it just be delivered? In some cases, this is possible; small, low complexity, low risk initiatives can realise a quicker time-to-market by expediting the implementation of a solution with only a light IT architectural touch. For larger undertakings however, focusing only on the delivery of an idea can undermine its success to an unrecoverable degree and the cost incurred by architecture work can be a fraction of the cost of a poorly performing (or failed) solution.

Good IT architecture practices, much like any other activity that strives to ensure quality and consistency, can be likened to the letters in a humble stick of rock; they run all the way through, but they have to be there from the start because they simply cannot be put in afterwards.


[1] McKinsey and Company, ‘Delivering large-scale IT projects on time, on budget, and on value’, October 2012, Michael Bloch, Sven Blumberg, and Jürgen Laartz

[2]The Standish Group Report, ‘Chaos’, 1995.

[3] Oracle Corporation, ‘Why Projects Fail: Avoiding the Classic Pitfalls’, October 2011, Michael Bloch, Sven Blumberg, and Jürgen Laartz

[4]IBM Corporation, ‘Seven Reasons Why Information Technology Projects Fail’, August 2011, Joseph Gulla Ph.D.

[5] Zachman International Enterprise Architecture, Zachman Framework

[6] The Open Group, TOGAF