Enterprise architects need to use a broad variety of techniques and perspectives, delivering a varied set of artefacts and collaborating with other parts of the organisation to provide insights which cannot be attained alone. Many activities crucially important to modern enterprise architecture are not labelled as such. Some practitioners of the new techniques don't want to be "tainted" with the EA label, and identify as other roles. Meanwhile, traditional architecture frameworks want to control and own their ecosystems. This shouldn't put off enterprise architects, or anyone working at enterprise level identifying as a similar role, from using a broader toolset.

In recent years enterprise architecture has become a term that has fallen out of fashion. The enterprise architect job title has become inherently linked with heavyweight analysis by a small number of individuals. What many people perceive as enterprise architecture has stayed relatively static over the last 25 years - the rest of the IT industry has been transformed in that time, not only in technology but in ways of working. To most, an enterprise architect is somebody who practices TOGAF.

A similar thing has happened in other professions too. What do you picture when thinking of a lumberjack? A search of the internet for pictures of a lumberjack comes back with romanticised images of bearded men in checkered flannel shirts, holding axes. Do modern lumberjacks use axes? Chainsaws, harvesters, and feller bunchers are used for most work now. Do modern lumberjacks wear flannel shirts? To be honest I don't know, I only see romantic illustrations of them. They probably wear hard hats and high vis jackets!

Organisation

Let's start with looking at how enterprise architecture fits into an organisation. The terminology has evolved since the early days of enterprise architecture - other terms have also become established. Solutions architect (or sometimes solution architect) is used for "solution-level" design; outlines of systems aligned with the interests of the business, regularly interacting with other systems. There are also technical architects, who focus on supporting implementation and delivery of those solutions. People still use the term software architect as well, but a software architect could be doing either technical or solutions architect roles - it could even be a mixture of both, depending on where projects are within their lifecycle. There are also plenty of software architects who practice enterprise architecture, some of whom even refer to themselves as developers.

In a simple world, the enterprise architect works with the above architects by identifying and prioritising the problems within the enterprise that require solutions. We aren't in a simple world though, and thus the scope of the role is much broader. We will come back to this later. The below diagram illustrates the model, but doesn't imply a team or organisational structure.

A recent trend for technical leadership titles is the staff+ path, which are technical leadership roles from staff engineer and above. These are influential roles, but not associated with traditional enterprise architecture outputs. Despite it being described by many as "the technical leadership track", architecture too is a technical leadership track. Will Larson suggests that architect is a specialised staff+ role, but this doesn't acknowledge that the experience of an individual supports the different roles. You can't parachute a Right Hand into an Architect role. You can assume those behaviours in the way that teams assume interaction modes in Team Topologies, but the experiences needed to support the roles are different.

Getting enterprise architecture out of its rut requires architects to work closely with other staff+ roles. It doesn't replace the need for enterprise architecture but makes the architects more accountable and broadens the opportunities for collaboration. staff+ engineers will carry different perspectives, and this is the power that needs to be harnessed.

An alternative to defining enterprise architecture

We have noticed that defining enterprise architecture is a controversial subject, causing heated disagreement or vehement denial of their role among practitioners. Forrester has seen this too and has identified an alternative approach, by analysing how enterprise architects deliver value. That analysis identified that enterprise architects can deliver value along a strategic and project value axis (X), and a business and technical value axis (Y). I'll refer to project as delivery, as that's the underly priority. Over time the work shifts around the different quadrants, depending upon the needs and priorities of the enterprise. Some examples have been included for illustration in the diagram below, but even the same activity is likely to differ in its position depending upon its context and lifecycle.

We have identified that different types of value address different needs and priorities. Delivering different types of value requires different capabilities and skills from the enterprise architects, interacting with different parts of the enterprise. So now is the right time to ask, in a sea of differences, should the enterprise architect follow the same approach across the board?

Of course not, and this is the problem. We need to loosen up, and stop treating enterprise architecture like it's a rigid discipline, with framework gatekeepers constraining how people work. There are too many solutions that promise to unify the approach, and they have claimed enterprise architecture as their own.

Using the correct tool for the job

Given the broad variety of problems that an enterprise architect could be called upon to solve, they need to use the most effective tool to get the job done. This is where we need to bring together a variety of perspectives and techniques.

• Choose your tools based upon your context. A painter doesn't use a paintbrush for the whole of a wall - but they would for cutting in around edges. When they do use a brush they will chose a type and size to match their activity. They will even use two or more tools simultaneously - masking tape, brushes, benches, extensions, or even thinners. Good architects should be equally as flexible.
• Would you expect to be able to keep all of your tools in a single toolbox? Enterprise architecture frameworks have a vested interested in providing you with certifications and new releases. They want you to use techniques that are within their ecosystem. You're better off if you don't constrain your toolbox. Not all methods that are useful in enterprise architecture are labelled as enterprise architecture techniques - you can use tools in lots of different contexts.
• If you can't see where to hammer, what do you do? You will often benefit from using multiple perspectives. It is widely acknowledged that you cannot model a whole enterprise, they evolve too quickly and are very complex. It is more important that you look at aspects of your enterprise from different perspectives instead, as this will reveal information which would otherwise have been hidden.
• If you look on your problem from a different perspective, you may find that actually you will find root cause solutions, rather than applying whack-a-mole patches.

There are plenty of techniques that are being used across IT landscapes which are not labelled as enterprise architecture activities. To illustrate, we have drawn up the below table that provides examples. The table is far from exhaustive, and the values are draft, but you can hopefully see that you get radically different perspectives, very quickly, from embracing modern patterns. Some of the approaches were originally identified by Mark Richards - see Lessons 50, 51 and 52 of Software Architecture Mondays. Model-driven and initiative-driven are also approaches recorded by Mark.

Each approach has been provided with quality attributes to demonstrate some of the ways that an an enterprise architect may choose between approaches. Definitions of those listed are as follows:

• Velocity Speed at which an initiative can provide value.
• Effectiveness Whether the initiative results in the desired business outcome.
• Accuracy How accurately the approach represents its intended outputs.
• Accessibility Size of the audience, and whether the audience would understand the artefacts.

It is worth keeping in mind that as in all parts of architecture across IT, "it depends". The approaches could be combined - Inventorying implemented as part of a platform engineering effort would be using a continuous approach, and so characteristics would generally align with the continuous approach, but would require the high level of systems maturity to enable it.

You may need to scroll horizontally to see all of the columns in the table.

To summarise, there are lots of excellent approaches available, which within their own narrow niches have very positive characteristics. Interactive and Operational approaches give better informed decisions, and change how enterprise architecture is defined. Analytical approaches are also still useful, but are typically applied in very focused contexts. All approaches have their trade-offs, and those trade-offs will vary by context.

What are your experiences of these techniques, and what other approaches would you consider? If you would like to discuss any of the concepts we have written about get in touch.