View of Architecture

This page describes the Fragile to Agile definitions of Enterprise Architecture and Solution Architecture, what the difference is between them and how they should work together.

In our view, the “enterprise” in Enterprise Architecture has two meanings, both of which are equally important. Although individual areas of the business can be the primary focus for any of our engagements, the first and generally well understood meaning of “enterprise” implies that the scope of the architecture must be the whole of the business.What-is-Cartoon

The second but less understood meaning is that it must incorporate the entire breadth of design, including business, people and technology design. Whilst we recognise the importance of Technology Architecture, it is only one aspect of a true Enterprise Architecture. We appreciate that some practitioners do not concur with this assessment and consider Enterprise Architecture to only cover technology domains of design. However, we argue that this is only a subset of a full Enterprise Architecture and refer to this view as Enterprise Information Technology Architecture (EITA).

The final twist which leads to the Fragile to Agile definition of Enterprise Architecture is that it must be relevant to the business and deeply embedded in its process of implementing change. Otherwise it runs the real risk of becoming an ivory tower architecture.

So, with simplicity always front of mind, the Fragile to Agile definition of Enterprise Architecture is:

“Enterprise architecture is the alignment of business, people and technology design to ensure that together they deliver business intent.”

Implied by this definition is that Enterprise Architecture must be both a set of artefacts that achieves this alignment, what we refer to as “architecture the noun” and a process for actually architecting a solution, “architecture the verb”. Furthermore, this process must be integrated with an organisation’s standard change process and not conducted as a parallel activity. More importantly, it implies that Enterprise Architecture must be driven by business intent if it is to deliver its promised value.

If Enterprise Architecture is analogous to town planning, Solution Architecture is the equivalent of traditional civil architecture. It is responsible for designing specific buildings (solutions) in the town (organisation), ensuring that these adhere to the building codes (design principles) defined by the Enterprise Architecture, and contribute to delivering the vision for both (desired business outcomes for the organisation).

Fragile to Agile consistently encounter IT projects that fail due to inadequate solution architecture processes and artefacts used to generate the project’s business case and support the planning and design phases of the change. Another reason for the high failure rate of IT projects is that the planning and design phases are skewed towards deriving an estimate rather than the most appropriate design of the solution. Furthermore, the emphasis on determining time and cost without establishing the business intent and solution architecture for the change is the primary reason for project scope creep and delays.

Fragile to Agile has specifically designed a Conceptual Design Process, built on its Integrated Architecture Framework, to address these issues. The process ensures that delivering a solution that satisfies business intent is the priority, with time and cost as by-products. If the time and cost constraints are captured during the determination of the business intent of the change and the business stakeholder community is satisfied with the solution, the associated time and cost will be accepted. The two key deliverables of this process are a Solution Architecture Summary and Business Case.

By incorporating both our Enterprise Architecture and Solution Architecture disciplines on the same Framework, we have greatly simplified governance and materially reduced the risk of “ivory tower” Enterprise Architecture.

The following are the key differences between Enterprise and Solution Architecture:

  • Enterprise Architecture must reflect the whole organisation and incorporate multiple projects and business initiatives; Solution Architecture is project based only;
  • Enterprise Architecture is strategic only, Solution Architecture is conceptual only as illustrated in our Integrated Architecture Framework:

02010201-IAF-Picture-V2.0

  • Solution Architects should be involved in developing Enterprise Architecture;
  • Solution Architects are involved in logical design to ensure software engineering adheres to Solution Architecture but Enterprise Architects should not be involved in this process;
  • Enterprise Architects must also be involved in Solution Architecture delivery as the function of Solution Architecture is two-fold:
    • To ensure compliance with Enterprise Architecture principles and patterns
    • To identify opportunities for sharing across solutions

“Whatever you can do, or dream you can do, begin it. Boldness has genius, power and magic in it” – Johann Von Goethe