Architects (Solution, System, Software, UX) in Enterprise Agility
Recently I was observing the Pattern-Oriented Design class for the Tech leads & Architects. At the start of the class, as part of introduction, the instructor had a few questions to get an assessment of the group's awareness to Design Patterns and coding experience: Three of the questions were: “How long have you been coding?”; “Which patterns have you used or know of?” and “Which language(s) do you know?”
I ask similar questions at the start of my sessions and hearing some of the answers to the above questions hence time triggered me to share my thoughts. The answers that caught my attention this time and previously are: “I am an architect, I have not coded in years”; “I am a new architect and I look forward to advancing to a position where I no longer work with code”; “I’d love to continue coding, at least some amount, but I probably won’t have time.”Just to bring the point home, these responses were disturbing.
I got thinking why do I hear these so often or should I say, “for the sake of what are these being said” and raised quite a few questions in me; since when did growing in a technical role mean separating technology, architecture from delivery? How do architects expect to set intentional architecture and guide the delivery through emerging design or even play within their enterprise without staying plugged into the teams that implement an architecture or technologies? Or, better yet, implementing one themselves? How does an architect expect to stay nimble in response to changing needs | requirements without staying connected to the delivery?
I strongly believe and recommend a good architect must work closely with the delivery team. This is imperative to evolve a successful architecture, which leads to a successful delivery of highest business value fastest in a predictable and sustainable manner with built in quality.
Collecting insights through evolving learning cycles and providing leadership thereby and thereto are two key benefits of architects staying engaged with the delivery. I’ll try and shed some light on these two key benefits per my opinion.
Insights from Learning Cycles
An engaged and invested architect will be present to collect insights and feedback first-hand and then work with the team to include the learnings or mitigate any deficiencies observed. Insights, learnings or feedback can evolve from a number of circumstances in the ecosystem such as changes in enterprise standards, changing or evolving functional/non-functional requirements, and opportunities or challenges discovered during implementation and testing.
The earlier the learnings are identified through the emerging design the faster the architect can incorporate the influence to evolve the architecture.
When the architect is not actively engaged with the delivery team then this learning can take weeks or months to bubble up, usually being very late in the delivery cycle and thereby making it more difficult to incorporate the changes as an evolution, almost asking for a pivot or accepting compromise(s) as the architectural decisions usually encompass things that are most important or hard to change, this lag in feedback only compounds when significant architectural changes are required making the solution more brittle.
What does accepting compromises mean?
Discovering architectural deficiencies late in the cycle usually leads to workarounds and technical debt to “just get through this release.” However, the earlier this feedback can be captured and assessed for architectural impact, the more lean and agile the entire delivery flow will be, and more risk will be ROAMed (Resolved, Owned, Accepted or Mitigated) sooner.
Leadership
Providing leadership is a primary responsibility of an architect. Leadership takes many forms, all of which are important to the successful implementation of any effort and its underlying architecture.
Architectural leadership requires the architect to effectively communicate the “big picture” to the team for successful realization. The best way to relay this information is by collaborating with the delivery team and having regular cadence based contextual discussions, not through one document or one meeting or one speech. The architectural guidance must be reiterated throughout the delivery cycle. It is all too easy to get caught up in the heat of delivery and lose sight of the overall goal, when walking through | working in the forest we can only see the trees and not appreciate the landscape of the forest. Having an architect that is continuously engaged will help maintain a consistent alignment to the vision and system will be able to maintain an appreciation for the landscape of the forest when walking through the forest appreciating the trees.
Technical leadership stems from the fact that the architect is often highly experienced in development and delivery. A goal of the architect should be to educate and grow the development team. Sometimes there are specific tech leads that play this role, but why horde the experience gained by the architect? Not only does this interaction benefit the team as a whole, it benefits the architect to understand some of the common issues the development team encounters. This is the two learning cycle built in the delivery system.
Mentoring is a form of non-technical leadership that an architect can provide to a team. Topics like working with non-technical people, embracing Lean & Agile principles, defining an architecture, and modeling architecture are all important skills for growing developers and future architects. Much of the training and knowledge of an architect’s role is gained by way of on-the-job experience as opposed to more formal, classroom-type educational opportunities. An architect should embrace this tendency and make architectural learning active rather than passive.
Summary
To achieve the intentional architecture, the architect must stay invested and engaged with the delivery team throughout the life-cycle. Staying engaged promotes early learning cycles and a quick feedback loop in the emerging design. It thereby ensures for the architect to communicate the architectural vision and provide technical leadership to the team in alignment to the vision. Although the architect should code, as per above included belief and recommendation, there are other ways for the architect to stay engaged with the delivery, providing leadership as a coach, mentor, peer pair etc enabling and enforcing collective ownership. A key goal is to avoid the “ivory tower” architect persona that decrees the architecture up front and then is never seen or heard from again. Strive for a collaborative relationship with the delivery team, working together to identify and remedy architectural challenges as early as possible to deliver a successful architectural runway always enabling to deliver the incrementally growing business value.
Presented By:
VIKAS KAPILA (SA, SPC, SPCT)
Vikas KapilaWith 17+Years Solutions Delivery, Consulting and Coaching, Vikas is a transformation practitioner with a passion for applying Lean-Agile principles, behaviors and practices to enable delivery of highest business value with built-in quality at the earliest in a predictably and sustainable cycle. He is a Lean-Agile Enterprise Agility Coach. He excels at quickly delivering business value, simplifying the seemingly complex and delighting customers. He is able to achieve these results by consistently building radically prolific, high performing teams by believing to look listen & learn before initiating collaboration, coaching, training and facilitation.
Vikas has Trained and companies coached with 724 Solutions, Acision, Andanza Technologies, Bank Of America, Cisco Systems, Capital One, Mobixell, National Geographic Society, Peer1 Hosting, Scottrade, Tennessee Valley Authority.
His main roles are Agile Coach, Scrum Master, Solution Architect, Agile Program Manager, Product Manager, Product Owner.
