Talking about the added value of applying Agile Architecture in your organization, we see fewer and fewer “IT architects” in organizations. Is that because we do not need Architects anymore?
Do we need Agile Architects or do we need to do Agile Architecture?
In fact, nowadays, Architecture has shifted from a job title to a role. And this role or this function can also be assigned to a whole team. Even different people working in product teams can fulfill the role together.
Mostly, this is due to the fact, that modern Agile Architecture requires a broad skill set to be done right as a business function. Read more about this here: Putting the A of Agile into Architects by Winfried Scheulderman.
Significant decisions about your IT landscape
In times, when many organizations are facing or find themselves in the mid of a major (Digital) transformation, Enterprise Architecture helps you to align your organization, your initiatives, and the products you are developing with your goals. These goals can be business drivers or transformation goals.
It also helps you to manage dependencies that occur once you have started with lots of changes in an organization and keep them aligned with your strategic goals.
So, do we only need Architecture when we are going through major changes?
- Architecture helps you to make significant decisions about the key design of your IT landscape: components, systems or, domain-related. It can refer to all applications or systems you need to align with the business strategy.
The main value of Agile Architecture is to ensure that you are making the right significant decisions in all layers of your organization. That implies that you cannot limit the role of architecture to one single person within a growing organization. Different types of architecture roles add a different kind of value to the organization.
An Enterprise Architect adds a different kind of value than a Tech Lead or Lead Engineer, who does architecture as well.
Portfolio management, Program management and the “business wish list”
But what about Portfolio managers or Program managers? -Agreeing that you cannot load the burden of all significant decisions on a very limited number of shoulders, it is obvious that cooperation is key, especially with Product management and Program management.
However, there are some differences to bear in mind:
Portfolio management and Program management are responsible for gathering all business requirements, the so-called “business wish list”. But when it comes to implementation of the wish list, please have an architect enter the stage:
Let’s take the example of a specific domain with a dedicated domain portfolio manager and domain program manager. They are responsible for developing different products within the domain. The domain architect on the other hand is responsible that everything which needs to be developed and what needs to be implemented, complies to the overall architectural guidelines, and is implemented in the right order.
For example, if there is a specific business requirement, the architect makes sure that all the right platforms and enablers are in place first instead of quickly realizing a specific feature request.
The architect watches over the broader perspective of the IT landscape, manages complexity, takes care of security, ensuring non-functionals are addressed in a proper manner.
Of course, Portfolio management can also take care of this aspect, but in practice, we must focus on the skills required. It is not about the name of the job, but about the skill set to take care of architecture. In the end, people from different functions can attribute their specific skillsets to the common effort of “doing architecture”.
Skill requirements in Agile Architecture
While the traditional training frameworks for architecture, e.g., TOGAF address processes and models, they leave out skills like stakeholder management and modeling, or analytic skills. Additionally, we are also noticing that DDD and strategic DDD become important skills in Agile Architecture
Another one to consider is technical leadership, experience in the technical domain which can be described as “know your stuff”. Also, do not underestimate communication skills. Even if you know your stuff very well, it won’t help you if you cannot get your message across.
Driving technical change or creating a solution design, your results must get out there and make impact. That requires a certain level of communication skills: verbal abilities and the abilities to communicate your architecture in an efficient way.
Finally, let’s talk about modelling. If you want to take the architectural responsibility, you should be capable of developing the right models at the right moment for the right audience.
If you liked this article and would like to discuss the future of Agile Architecture, get in touch with me or check out Xebia’s Agile Architecture services.