Design authority is key to IT transformation. The IT technology base is changing: the acceleration of the move to cloud and the generalization of agility are forcing architects, who are increasingly on the critical path. Our experts Tech for Business share 5 tips for building a Design Authority that delivers on its promise of agility and solid architecture.
The role of the architect is essential
Some of the world's best-known organizations have moved towards Design Authority models, and have succeeded in taking architecture teams out of the realm of constraints. Better still, they have now become essential levers for accelerating transformations.
As a visionary, the architect must integrate constraints and specificities in a world where the technological base is constantly changing.
Often seen as a one-man band, he is forced to accumulate technological specialties and experience. That's why this key resource is under increasing pressure and unavailable.
Organizations want to see him evolve from his traditional position of strategic architect to that of combat architect. He is expected to deliver studies, recommendations and architectural principles, while maintaining impeccable reference systems.
This transformation, which has been triggered by the increase in transformation projects, the democratization of agility and the deployment of new technological platforms (cloud, platform, SaaS, etc.), is shattering traditional architecture team models.
But the missions of an architectural team remain unchanged
- Bringing coherenceso that IS bricks communicate with each other effectively and form a coherent whole.
- Decision support to identify and clarify the choices to be made.
- Scoping as the key to designing an IS component, and how it will evolve.
- Expertise in specific technological areas is obviously in demand.
- Monitoring system evolution over time, including tracking obsolescence.
Design Authority as a solution
Architecture is a transmission belt for agile organizations (see our full report on agile IS governance). An isolated, top-down team is unlikely to be effective. Architectural teams need to be as close as possible to the impact of their decisions, and to the feedback they receive from their teams. Their ambition should always be to arouse interest rather than impose constraints.
1. Working on capabilities
Architecture departments are often faced with a difficulty. When it comes to the enterprise architecture vision and the associated roadmap, there is a mutual expectation between management and architects. This expectation often takes the form of a passive exchange between the two parties, which is rarely resolved. In fact, it is often this situation that gives rise to the impression of prescriptive, out-of-context architecture.
So, to avoid this frustrating loss of energy for everyone, it's wiser to work on a capability scale.
Advantages
- The scale of work is actionable, circumscribed with trades / tech
- A natural link between product and data
- The discussion between the parties becomes concrete.
Points to watch
- The proximity between the company architect and the solution architect must be significant, without any notion of subordination.
2. Ritualize ADR (Architecture Decision Records) within your Design Authority
We use ADRs (Architecture Decision Records) to document the subjects under study. They are the natural tool between the technical teams and the architecture team. Principles and decisions are stacked up like logs (there's no such thing as a perfect "initial framing") and are made on the scale of capabilities.
Central or more local decisions concerning a single team (or even a single component) are stored and versioned in this way.
The ADR contains the background, the principles / decisions, and the associated context.
Context is essential: it explains why a choice has been made, which may change in the future. A weekly review, with the Tech teams, of the ADRs impacted by the work in progress is a good practice.
Advantages
- It's easy to integrate the Design Authority as a new architect: ADRs document the "life" of the IS, making it easy to get to know it.
- Reviewing ADRs with tech teams facilitates a pragmatic bottom-up approach.
- Changing decisions is no longer an issue, as the scale of capabilities means that impacts can be controlled.
Points to watch
- Discipline must be maintained throughout the ADR life cycle, to facilitate transfer and takeover.
3. Developing Tech culture is also a mission of the Design Authority
The architectural team's know-how, technological knowledge and market experience are often unrivalled. Although architects like to exchange ideas with each other on a regular basis, their knowledge rarely crosses team boundaries.
A Design Authority must spread a broader culture of technological curiosity throughout the organization. The weight of managerial practices is distancing everyone a little more from tech: the Design Authority's mission is to regularly put it back at the center.
This is why it is often useful for the Design Authority to organize :
- events,
- talks,
- communication,
- influence around technology in general.
Advantages
- The Design Authority's accessibility is reinforced.
- The shared discourse leads to the popularization of expert visions.
- The meaning and leadership of the Design Authority is better understood by everyone.
Points to watch
- Target "general public" events, meetings and content, and avoid sliding into expert debate.
4. Dimension on deliverables, not on resources, for better Design Authority efficiency
The most essential trick is to switch the team's operational model. This involves drawing up a list of deliverables to be achieved over a given period, regardless of the team's resource capacity.
The Design Authority will have to carry out X studies, write Y technical architecture files and Z detailed technical scopes.
The Design Authority then acquires the capacity required to meet its needs. A panel of specialized suppliers can support the model and its scalability.
Advantages
- Availability of the right expertise for the right subject (choose the subject architect to handle the study, not a cross-functional architect who's always changing subjects).
- Ability to handle both volume and substance
- Predictability of the model in its results orientation
Points to watch
- The need to build a documentation base and a mature onboarding system, to quickly integrate new architects and avoid losing the knowledge of architects leaving the Design Authority.
5. Contract with partners to manage scalability
There's no such thing as an architecture team with online experts in all business subjects and technologies. It is essential, beyond the core team, to surround yourself with companies capable of providing this capacity and scalability (short study missions, on a variety of technologies, with experts per technology / business).
The implementation of a contract providing this scalability and adaptability must include a penalty and performance dimension in relation to the desired results.
Advantages
- Highly scalable model
- A controlled budget (based on a result by deadline, not by means)
- Systematic subject expertise
Points to watch
- Requests must be anticipated at least one month in advance, to enable the supplier to commit to his ability to find the right architect.
DISCOVER OUR STUDY
Much more than a simple barometer, we invite you to dive into the trends that will redefine the French technological landscape in the years to come.
This study is intended as an open window on the practices adopted by CIOs to navigate in an environment where agility and adaptability are essential qualities.
Through in-depth analyses, inspiring testimonials and real-life case studies, we've put together a comprehensive overview of the forces shaping the future of CIOs in France.
