LifeinTECH

At the end of 2015, I formally become an Enterprise IT Architect.

This was a natural progression, building from the experience I had gained through a number of analyst, specialist and consultancy roles, as well as my time as a solution architect working in commercial IT.

Unfortunately, Enterprise IT Architecture (emphasis on the IT) had really lost its way in my company. Therefore, one of my first tasks was to help re-establish the organisation and work out how it could regain credibility and clearly demonstrate value.

In my opinion, Enterprise IT Architecture was struggling because it had become an “ivory tower”, where a group of individuals would meet periodically to discuss and strategise.

These discussions would tend to be very academic, leveraging methodologies from TOGAF, CEB, Gartner, etc.

Although these methodologies can certainly be valuable, without a strong connection to the business, context and situational awareness, the output can lack practical relevance.

Worse still, the complexity of the models used in methodologies such as TOGAF can be very difficult to consume for anyone who hasn’t received specific training. This can result in poor adoption and feedback that Enterprise IT Architecture is out of touch with reality.

In summary, Enterprise IT Architecture had become disconnected from the business, overly reliant on theoretical models and enabled through a legacy governance model that was generally perceived as a barrier, instead of an enabler.

With these challenges in mind, we decided to develop our own structure and methodology, pulling inspiration from a wide range of sources, but always looking to aggressively simplify and rationalise.

Structure

Structure is directly related to the business model and organisation hierarchy, as a result it will likely look different for every company.

However, I am a firm believer that Enterprise IT Architecture must be embedded within the business, not an exclusive club with dedicated, disconnected resources.

To achieve this outcome, Enterprise IT Architecture must be a virtual community, made up of the “Lead IT Architects” from the functional IT teams (different parts of the business).

This structure helps to guarantee that the discussions, strategy and decisions are driven with business context and strong situational awareness. It also ensures that all parts of IT have an equal voice, helping to drive enterprise alignment.

To help support the conversations, specific IT architects are positioned as “Domain Facilitators”, covering Information, Application, Technology and Delivery. The purpose of these individuals is to help coordinate domain expertise across the company, ensuring the right people from the functional IT teams are engaged.

The goal of the Enterprise IT Architecture virtual community is to provide a north star for the enterprise, through the creation of principles, positioning and patterns. The Lead IT Architects are then responsible for distributing the information across IT, helping to drive better strategic decision making, by triggering the right solution architecture conversations.

Methodology

The methodology is relatively simple, split across three tiers: principles, positioning and patterns.

I do not intend to cover each tier in detail within this article, instead simply provide a high-level overview. I will then follow-up in future articles, providing additional detail.

There are four principles assigned to each domain, covering Information, Application, Technology and Delivery.

The rationale behind having only four principles is to ensure that they can be easily consumed and remembered. Historically we have had hundreds of principles, which although are perfectly valid, results in limited adoption as people don’t have enough time or commitment to truly understand them.

The domains Information, Application and Technology are likely very obvious and also link with materials provided by TOGAF and Gartner. However, Delivery is a little different. This is in recognition that Enterprise IT Architecture must also influence the execution of work, not just position theoretical models.

Positioning is focused on enterprise technologies, providing a reference architecture that can be used as a blueprint (also described as a play-book).

We developed a specific reference architecture structure, split across seven layers.

• Security
• User Experience
• Platforms
• Information
• Integration Fabric
• Infrastructure Foundation
• Delivery Tools

Each layer includes multiple complimentary enterprise technologies, as well as inherently promotes the principles. It can be used to help communicate the enterprise technology landscape, as well as to ensure clear positioning, which reduces duplication and helps to maximise the return on enterprise investments.

The reference architecture is arguably the most important part of the methodology, as it is very tangible and forms the basis of solution architecture when consuming enterprise technologies.

Finally, patterns, which are built directly from the reference architecture. Each pattern describes how to leverage the enterprise technologies to meet specific use cases.

Patterns focus on real-world examples, whilst also helping to further embed the principles and positioning. Where appropriate, the patterns also link to accelerators, which could include code packages, modules and/or API endpoints.

For example, most companies must develop and maintain a number of websites as part of their digital eco-system. Although the purpose of each website is likely unique, the underlying application architecture is probably consistent, meaning that the foundations could form a pattern and corresponding accelerator. This approach can help reduce development time as well as improve quality and security through standardisation.

Conclusion

In summary, the structure focuses on embedding Enterprise IT Architecture within the business, ensuring discussions, strategy and decisions are driven with business context and strong situational awareness.

The methodology focuses on simplicity, with the principles providing a north star for the enterprise, as well as being easy consume by all IT. The positioning and patterns target architects and solution engineers, with the goal to reduce duplication, improve speed to value and quality through standardisation, as well as maximise the return on enterprise investments.

In future articles, I will share more details regarding the principles, positioning and patterns, including examples of how they can be used to drive clear value.