Вы находитесь на странице: 1из 6

PUBLISHING Saved More Publish

Normal

Image Credit - https://en.wikipedia.org/wiki/File:ArchitectureCartoon.png

Is the "Architect" Dead or Alive?


This thought provoking article https://dzone.com/articles/the-death-of-
architecture in dzone triggered a spark about the role, titles, ownership and
touched a sweet spot deep within; My comments grew too large, to the
effect that the "post comment" button in the DZone article hid itself away!
Hence this post! Every blocker is an opportunity!

An architect can never be dead, as long as engineers would practice and live


by the tao http://www.bredemeyer.com/tao_by_Kruchten.htm 

Architects are the enablers and the glue; They understand the triangle of
people + business + technology. They see the bigger picture and yet deal
with the details. Architects see things through multiple perspectives and ask
the right questions. They ride the chaos and bring order.
Why debate this now?
PUBLISHING Saved

A Major reason IMHO, is due to the agile transformation and changing


expectations, especially of engineers, managers & the need for "self
organized" teams. Every agile framework is different, leading to ambiguity
about the place & role of an architect in the agile world.

Appreciation for the Role of an Agile Architect and Agile Architecture,


needs more advocacy than ever before.

The best team one could garner in the new world (the coveted "self
organized" team) would have engineers who are mature, able to deliver
features which delight customers; with maintainable code, following high
standards & best practices, aided by processes that can support business
smoothly at-least for a few years with least cost and most benefits (before
things turn to being legacy)!

To meet these expectations an engineer should understand & have mastered


the triangle of people + business + technology.

Well, that certainly sounds Utopian!!

In other words, we are looking for architectural traits in engineers.
But it's hard to realize and pragmatically speaking, the teams should have a
healthy mix of engineers + architect(s), where architects could still be
working on multiple projects.

So, Should the role of an architect be eliminated or enhanced?

The architect's role should be enhanced. It's not pragmatic to expect all the
engineers think and act like an architect. Right candidates need to be
identified and nurtured.
So,Pwhat
U B L Idoes
S H I Nit
G take a engineer to transform into an architect? Gurus like
Saved
Philippe Kruchten, Dana Bredemeyer, Ruth Malan, Simon Brown, Scott
Ambler, Martin Fowler have shown us multiple paths!!

It's a journey and an individual's choice to build their careers as architects.

What is the other side of the coin? And how to address the concerns?

On the other hand, the organization is faced with the problem of ivory tower
architects, which is a reality as well.

So, what should a transformational leadership do in the best interest of the


enterprise and people?

1. Should they make the roles and expectations of architects clear?


Leverage the strengths of people to the best? Nurture more architects?

2. Should they eliminate the symptoms rather than addressing the root
cause? What are the real problems? Is it with the roles or more around
adoption of an agile methodology or framework (i.e., a (fr)agile
ecosystem), and/or dynamics in the struggle to adopt to the changing
needs?

The Pill: Both need to be addressed - a. Enhance the roles of an architect


and b. Address the real problems @ their root.

A. What could be done to enhance the role of an architect?

Follow & live the recommendations from the respective agile methodology /
framework.

Scrum -
https://www.scrumalliance.org/community/articles/2017/november/the-
agile-solution-architect
1. PCreate
U B L I S opportunities
HING for more hands on: own and code over and above
Saved
design & reviews

2. Give accountability for delivery of organisational goals: Drive from the


trenches - share the pains first-hand.

3. Make them visible than being the invisible ghosts; Give them enough
authority that's needed to fulfil their accountability.

4. Create opportunities to connect with the grass roots of the echelon to


touch and feel the reality so they can adopt their architectures rightfully
& course correct themselves.

5. Leverage their strengths to groom and mentor the engineers (creating a


cascading effect through the levels) towards the path of tao
http://www.bredemeyer.com/tao_by_Kruchten.htm!

6. Make them share their rich knowledge - Seriously, there's a dire need &
calling for dedicated efforts with focus to cultivate the *inner architect*
within a engineer, to cultivate a mindset to adopt best practices & an
engineering mindset by building continuous, consistent demands and
setting a high bar.

B. How could the real problems be addressed?

Let's take role changes as an example.

Ironically, agile is all about people coming together and the agile journey
itself impacts people in an unexpected adverse manner (more often then
not!).

How?

By Designation changes!!
Does
P Uagile
BLISH frameworks
ING recommend designation changes?
Saved

No! They only recommend roles.

And how are these roles mapped to people then? via a Designation Change!

Why So??? 

That's a worthwhile question for organizational leadership to ponder!

How's the bottom line impacted by these designation changes during an


organizational transformation? How adversely does the designation change
impact people? How is this impact measured & acted upon?

1. Fix the (fr)agile development processes! Killing the architect's role and
re-assigning these roles onto engineers and managers isn't what agile
recommends.

2. Inculcate & invest in developing people, soft-skills and in creating a


culture that nurtures bonding between people without conflicts. Create
that motivational environment befitting every organization's ecosystem.

3. Measure & Quantify the ***Real business benefits*** of the agile


adoption within the enterprise!! Retrospect if the teams live as per the
spirit of the Agile Manifesto rather than practising agile rituals as a tick
in the box.

4. Measure and be cognizant about the cost of agile transformations &


impact to the bottom line, employee morale, productivity, cost, and time
to market! The challenge & bitter pill is to look in the mirror to Measure
& Quantify!

5. Build & evangelize a framework to apply the learnings from one project
others. Track how are best practices are helping the organization in
Pfaster
U B L I Sturnaround
HING & responsiveness? Saved

Conclusion

Let the Architect be! Build more of 'em! Live the Tao! Live the agile 
manifesto! Nurture deeper insights of agile methodologies and 
frameworks!

Long live Management, Long live the transformational leaders! Long live
Engineering, Long live the engineers! Long live Architecture, Long live the
dead (Architect)!

Вам также может понравиться