Enterprise Architecture in the era of Agile…

stevang · ‎03-16-2023

What is Architecture in the current era where we all are Agile (or we all are supposed to be Agile)?

Agile Architecture is not some brand new “framework” or new “style” or Architecture… No, no, we really do have too many different frameworks…

So. what’s new? What has changed from the era of TOGAF[1]? Isn’t SAFe[2] actually addressing Architecture “Agility”?

Could be, but no matter whether I look at TOGAF of SAFe, I see too many “definitions”, too many “tools”, too many “processes”, too many “procedures” etc. Weather we are building Baseline and Target states, supporting Architecture Assessments, doing PI Planning or so, it just looks to me as too much “ceremony” is involved – and I do find this “ceremony” to be a bit annoying …

Another point, while practicing those frameworks, I’ve started wondering, where do we draw the line between Architecture, Delivery, and Operation? Well, it seems we don’t. Actually, implementation was always part of TOGAF ADF. Obviously, SAFe is pretty much emphasizing DevOps. So is this is problem?

In fact, on this Architecture to be well connected with DevOps, I do agree – precisely because I do believe Architecture should produce artifacts which can be “easily” consumed. But then, if Architecture is supposed to be Agile, why are we bothering Architects with so many “framework” formalities?

What is an Architect role in the Intelligent Enterprise?

In the last decade, IT transformation projects have evolved from the IT Landscape Modernizations & Business Process Automations; through “never-ending” Digital Transformations, reaching finally new “buzzword” – Intelligent Enterprise. What’s next?

There is a famous quote from McKinsey’s study “70% of the large-scale change programs don’t reach their stated goals”[3] – this was quoted numerous times, and with the reason.

Figure 1. Not achieving?

The thing is, IT projects are becoming increasingly more complex, while business demand for “more” is growing faster and faster. Delivering one big Digital Transformation does not give us a break – while building one transformation, we immediately must adopt changes and/or plan and execute other transformations. In fact, we are in the “state” of the Continuous Transformation[4] – this is an infinite loop (perhaps just like DevOps?) which we as Architects must embrace. This is the price we must pay to advance our business to the Intelligent Enterprise.

Figure 2. Continuous Transformation

How do we achieve this Agility?

If Architecture is adopting the Continuous Transformation, if Enterprise is changing toward the Intelligent Enterprise, then Architect role is also changing, right?

Let's go step-by-step.

Thinking path…

What is that we must accomplish as Architects?

We must preserve structured approach, but not at the price it is slowing us too much – versa-vise, we do not want to be too fast, so we lose the control over the transformation;
We want to provide an immediate business value, but not necessarily to address all problems at once – as it is simply not viable;

So, an Architect is a pragmatic thinker – setting realistic and achievable goals.

Styles, approaches… Waterfall, Agile…

We may build a house without a blueprint. But try to build fifty story building without a blueprint? Well, it will just not work. There are so many things which must be interoperable in the large building – it’s a whole different dimension. You do not build this building “Agile”. You need to plan everything upfront. Yeah, this is Waterfall, right.

But then, why is Waterfall approach so bad, why is it so commonly “disliked” these days? Why is Agile “advertised” as a Solution for all Problems? Well, it’s not! Agile as an approach or methodology is absolutely okay, but Agile as an object of “worship”, absolutely not. Anyway, this is not about – which approach is better Waterfall or Agile? First of all, Waterfall approach may have embedded loops and iterations – and those iterations do not make it “Agile” per say. Also, Agile approach will freeze some content and deliver it in fact as a mini-Waterfall – and still it would be considered “Agile” overall.

Waterfall, or Agile – it’s not a philosophy, this is just an approach how to fit-the-needs (purpose & use). And those needs should guide us, which approach to apply in the particular situation.

So, an Architect is a conscious thinker – choosing the right path (approach) to bridge to Gap.

Leader, Motivator, Influencer or Supporter?

An Architect drives toward Architectural Decision. But how is an Architect doing that?

Does he/she lead others?
Or, is he/she motivating and “empowering” other people to do the necessary things – to work on building the Architecture?
Or, perhaps it’s about influencing and “provoking” people – so they make “desired” Architectural Decisions?
Or, maybe he/she just needs to support the community – until viable Architectural Decisions are made?

Simple answer – an Architect must do all the above!

There is no “one-size-fits-all” way of working. While empowering is always a good idea (especially in the Agile approach), leading by example is also expected in many situations (especially when we need to move fast). Of course, some Architect will be more skilled in some ways or working, while other in some other ways – just as some individuals will have more engineering (analytical) way of seeing things, while other will have more social (empathy) mindset.

Ideally an Architect is a versatile IT professional – being able to apply different ways of work, depending on the moment, situation, and the community of people around.

Architect is not a Delivery Manager…

So, Architecture has to be pragmatic, Architecture provides artifacts which can be consumed, Architecture is very much connected with Delivery & Operations (or DevOps in Agile), and for all this an appropriate Architecture Governance must be in place. But wait, an Architect it not a Delivery Manger, it’s not an Operations Manager, and it’s not a Project Manager or Scrum Master either.

Yes, an Architect may play different roles in the Organization – but there is (or should be?) a clear dividing line – an Architect is responsible for the Architecture “work”, there are other roles in the Organization who should be primarily responsible for the actual Delivery & Operations.

Architect is not a “master of ceremony”…

Both TOGAF and SAFe are overloaded, if you ask me, with a lot of “ceremony” – and if we look at each of these frameworks, an Architect is the one who must have mastery of all processes and procedures… Well, I do not really agree with this.

Yes, an Architect should respect the “ceremony”, but why should an Architect be “master of ceremony”? Again, an Architect is primarily responsible for the Architecture “work”, there are other roles in the Organization who should be responsible for the processes and procedures.

EA and SA

Well, true many do consider (and treat) EA (Enterprise Architect) as a "higher" job grade of IT Architect, sometimes observed by non-IT personnel as a ”senior” Business Consultant. However, I would disagree strongly with that perception. Indeed, Enterprise Architecture should be holistic discipline, starting from business drivers and goals – building the architectural roadmap on top the business vision. The work usually starts with EA. The actual solutioning would then be passed to SA (Solution Architect). But I would not even say SA is purely operationalization of the architectural roadmap on the specific technology or domain. Solution vision may address different focus domains, from business, info-system to technology. Holistic overview (or at least awareness) is still expected. Here again I see a tendency to treat SA as purely "senior" Technology Consultant or Software Engineer... Needless to say, I disagree with this tendency to “simplify” and shift everything to technology...

An Architect, whether EA or SA is a very senior IT professional and in fact, both EA and SA are working on Architecture Decisions together. While Software Architects are linked with software development, EA and SA are not software developers.

If we need to draw the border, in the traditional split, we could say:

EA is Strategy
SA is Operational

But this "border line" is a soft border and it is actually more like “touching point” in the overall Enterprise Architecture – because EA and SA must collaborate.

In the Agile way of “work”, collaboration is must:

EA is responsible to build Strategy (from Strategic Themes and then Portfolio Vision), but SA must also support strategy in his/her domain (i.e. should provide support for the Portfolio Canvas);
SA operationalize the Strategy in the domain (starting with Solution Vision), but EA also supports this operationalization (i.e. there could be cross domain topics etc.).

It is expected EA has content mastery over Strategic Themes and Portfolio Visio, while SA has knowledge mastery over the domain specific Solution Vision.

Figure 3. Border lines or touch points between EA vs. SA

While EA is usually perceived as a more senior Architect to SA, it may not be so. EA and SA do not have the same job descriptions. In specific product environments or domains, an Organization my need very-very senior SA to lead the work. Many Agile frameworks do not even foresee the role of EA, and some Agile frameworks do not necessarily see a role of an Architect at all.

Either way, an Architect is a seasoned IT engineer – performing IT engineering tasks in the Organization.

What is Architecture (for me)?

Architecture is the art of creation...

Yes okay, but let’s stop here with the art immediately. Architecture is both art and engineering discipline, but the purpose of Architecture is, and should be, an engineering primarily.

Just like comparing "construction" Architecture and IT Architecture; house may be simple brick house or Fallingwater house (by Frank Lloyd Wright)[5], but it is still a house which must provide homing to the people inside. In another words, the outcome of Architecture must be clear, tangible, and ready to be consumed. This is why Architecture is an engineering discipline primarily.

To translate this to IT; Architecture is not about producing bunch of artifacts – it’s about producing artifacts which can be “easily” consumed and turned into deliverables, which are then put into operations.

To conclude with…

We do need Architecture, but not for Architecture’s sake, not as an “free-style” art, but as an engineering discipline.

Frameworks can teach us, can provide us guidelines, but it’s all about common-sense. The way I see – in the era of Agile, Architecture is slowly crushing boundaries of all the frameworks, it must serve the Continuous Transformation and it must fit-the-needs of the Intelligent Enterprise, it can combine different approaches, and it should not allow to be “boxed” with too much “ceremony”.

Here I was bringing two Architecture frameworks, just as an example – but this is my general view on today’s state of the Enterprise Architecture, not on the frameworks itself.

What is your view?