We understand the true value of Enterprise Architecture and not just its rhetoric. For it to be realistic and workable, we believe Enterprise Architecture must be developed and right sized according to an organisation’s size, scale and the hard and soft constraints of its operating context and external environment. To avoid ivory tower or shelf ware architecture, it must be based on a broad business mandate and developed in a collaborative and inclusive manner to gain business involvement and sponsorship.

To maintain its relevance and reflect the needs of all stakeholders, it must also be seamlessly integrated with other management practices and decision making processes at various levels within an organisation. Consequently, it must generate working artefacts for all aspects of architecture that are practical and executable which remain relevant with changing business needs. A well-articulated and viable transition path to deliver explicit business value is also imperative.

Therefore, the Enterprise Architecture function must view technology as a business enabler, not a business driver. For it to be successful and deliver its promised value, it must be cohesive but not prescriptive; realistic not idealistic; progressive not static and constantly evolving to meet changing business needs and priorities. If these characteristics are not achieved, the Enterprise Architecture function runs the real risk of being ivory tower architecture.

The following is a list of the key tenets and principles of our philosophy:

Business drives technology not the other way round

The first tenet of our philosophy is embedded in our definition of Enterprise Architecture:

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

The order of design domain categories in this definition is deliberate as business design drives people design and together they inform technology design.

The EA practice is a cross-disciplinary function, inclusive of all design domains, and resides in an organisation’s business strategy area

Enterprise Architecture is not an IT discipline. It is our belief that for Enterprise Architecture to be successful it must be recognised as a cross-disciplinary function; part business and part IT. This is becoming more widely recognised with Gartner identifying the transition of Enterprise Architecture from the IT function to residing within the business as the final step of an organisation’s Enterprise Architecture maturity cycle. We concur and believe that it should reside within an organisation’s Business Strategy function.

Enterprise Architecture is developed in a collaborative and inclusive manner to gain business sponsorship

To generate the required understanding, involvement and ownership across the organisation, Enterprise Architecture must be mandated by the business and developed in a collaborative manner inclusive of all stakeholders.

Enterprise Architecture is an evolutionary discipline which delivers practical and executable design artefacts

For the function to maintain its business relevance, Enterprise Architecture must generate practical and executable design artefacts for all aspects of architecture that maintain their currency and integrity with changing business needs.

A well-articulated and viable transition path to deliver tangible business value is also essential

Don’t outsource your thinking

Fragile to Agile can assist in the development of an organisation’s Enterprise Architecture practice and/or develop some of its core artefacts e.g. a Business Capability Model.

However, we strongly advocate that responsibility for the function should never be outsourced, just as an organisation should never outsource its strategy function. We are happy to help you fill gaps in capability and capacity, but the organisation always owns the architecture. An organisation’s Enterprise Architecture should be owned by a senior executive, ideally the head of Strategy.

The core design artefact for Enterprise Architecture is a Business Capability Model

Our belief is that a Business Capability Model, a depiction of what the business does, is the most appropriate baseline business model that should be used to drive and inform technology alignment and is a fundamental tool in our overall approach.

Integrated Architecture Framework

The same framework should be used for Enterprise Architecture and Solution Architecture

One of the issues that we encounter frequently is a misalignment between the Enterprise Architecture/Architects and the Solution Architecture/Architects within an organisation.

We believe this is caused by the two disciplines following different methodologies and processes and subsequently delivering disparate artefacts.

Enterprise Architecture needs to be embedded in an organisation's Investment & Prioritisation Process

If Enterprise Architecture it is to be relevant within an organisation, it must provide executives with more meaningful information to influence funding decisions and inform their investment decision making.

Roadmaps must be based on a defined target state and deliver business value early and frequently

Fragile to Agile considers the following critical success factors are required for the construction and successful execution of a solution roadmap:

  • It must be designed to continually deliver improvements in short term iterative phases;
  • It must cater for both the organisation’s tactical imperatives and the strategic change;
  • It may contain some ‘throw away’ in order to deliver meaningful business benefit early e.g. exposing services for legacy applications that will subsequently be retired;
  • It must cater for the decommissioning of legacy applications and the revitalisation of heritage applications being retained in the target state;
  • The first phase should allow for the simultaneous execution of strategic foundation projects and efficiency based initiatives that drive cost out of the business to assist funding the remaining change program.