By Paul Preiss, of Iasa Global
I want to open us up to a conversation about narratives in architecture. These are deeply important to us as architects because they impact our shared stakeholders and their understanding of our value. My greatest aspiration right now is to help architects navigate these narratives and find a common voice of practice so that we can move beyond establishing our value and into delivery of it.
What is a Narrative?
First, it may help to describe what I mean by a narrative. This is the story we tell either directly or indirectly about our value proposition as a profession. I say profession lightly because until we establish a shared narrative we are unlikely to be able to make progress as a profession or on becoming a profession. It is possible but unlikely. I will explain the limiting factors of each narrative as well as possible solutions below. A narrative forms the basis of a belief system and in some cases a professional identity. For example when someone posts or says, ‘architecture is not about technology’ they are giving an example of a narrative. Just as much as when someone tells me ‘architecture is engineeering’ or ‘I am architecting the enterprise’ or any other of the belief systems people exhibit in their articles. I study these narratives to try to extract a unified voice and skills set for architects and retaining the value from each one.
There are actually not that many full narratives about architecture in existence right now, though there are endless variations on the details of the big ones. It is also important to note that I am not including any that don’t have a large enough or established enough following to qualify for this discussion. For example there is no narrative around AI and architecture yet.
In all the cases below I will try to be as positive about the narrative when explaining as possible when telling its story, clearly each of these narratives has a set of adopters and supports. I also want to include a set of detractors or objections which lead to opportunities for us to create a shared narrative. This is not to create argument though healthy debate is absolutely welcome.
What to Look for in A Successful Narrative
- Have a simple to understand value position to stakeholders
- Build a competency based practice with a shared competency model
- Allow for specializations to bring specialized benefits especially later in their career
- Are based on rigorous and continuous learning
- Have an external recognition factor (recognize their value outside of the organization)
- Set continous practice goals for themselves in all areas
- Recognize the incompatibilities in their individual narratives to succeed together!
The BTABoK is based in a ‘shared narrative’. It is based in the Transformation Narrative you can read below. It is open source and has hundreds of contributors through the years. https://iasa-global.github.io/btabok/index.html The goal is to capture the connected and useful techniques (things you can put into practice tomorrow) and ignore the hype and emotional arguments. I hope you will join us in this quest!
The Competing Narratives
Business Strategy to Execution
I want to start with what I hear most commonly from the business architecture community. This narrative describes a gap in modern business strategy especially as it aligns with operations (process), people and technology. The basic premise is that there is a gap in critical transformation. Strategy does not often become reality (to borrow from the brilliant Whynde Khuen) in the way that it was originally envisioned by leadership. This gap can be filled by artifacts and people who understand them. These artifacts are collectively known as the business architecture and the people are experts at their application in business contexts.
The artifacts in a business architecture include a number of very very important ones and any number of supporting techniques. These are the business capability model, the organizational model, joint value models such as OKRs and KPIs, strategy models such as SWOT, PESTLE, Strategy Scorecards and business models. There are too many of these to truly list and it is up to the business architecture practice to determine which ones a particular business needs to have a finished business architecture.
In this narrative, business architects do not own these deliverables. They fascilitate their creation across multi-faceted and multi-skilled teams of business people, sometimes including technology, sometimes not. The business architect is an expert at human dynamics (I try not to use the concept of EQ because it is so hard to manage and measure) and business strategy itself.
There is a great deal of value found in recent use of these artifacts in exposing valuable decisions in both business and technology. Capability models, strategy scorecards and change management skills not to mention the strong human dynamics skills of this group make them excellent at communication as well as fascilitation of change and of business outcomes. This leads to continued adoption and growth. This group excels at business value and business stakholder buy in and that must be retained in our profession at all costs. In addition based on numerous testimonials and assessments when business architects have had a background in technology they become very powerful representatives for the overall architecture practice in business circles.
Narrative Challenges
There are a number of issues identified with the current business architecture narrative. Similar issues often exist in the other narratives as well so please do not mistake these as unique or undue criticism of the business architects. The business architects themselves do not seem to have a rigorous skill model or career path model. Meaning, outside of the BTABoK there seems to be no unified view of the skills and competencies a business architect possesses or what their career path. Some current business architects come from a process management, business analysis or IT program management background. This often creates confusion as to how BAs are to be created.
The next area of challenge is technology and technical skill. This is a major hot button. Many people equate all architects with having a great deal of technical skill and they will often expect a business architect to have some similar background. Without this shared background in some amount of technology, the argument is that business architecture is unable to connect effectively to the other architects, somewhat like having two doctors who don’t share a medical background. This causes significant difficulty inside an company where shared architecture narratives are deeply important. This was highlighted in one large insurance organization (actually one of Jeanne Ross’ first case studies) where after two to three years the BA organization was removed while the solution and technical architecture organization was kept running. What we need to find is a way to keep BOTH of these communities working together and with stakeholders!
The business community has embraced this kind of business architecture for large organizations in some ways but has not determined where exactly it reports or how it relates to other architecture practices. Both the solution and enterprise architecture community have serious challenges in creating a strong bond with this narrative as it leaves out technology skills on which their narrative is dependent.
Software Structure and Delivery
The software architecture community is the oldest architecture community in the world. It was where architecture as a concept originated in the business community and was a direct result of the difficulty in structuring large and complex software delivery efforts. It also depends on embedded, device and product architectures related to complex technology development. However it boils down to very senior software engineers becoming architects based on degree of experience and expertise in both engineering and quality attributes in design and delivery of systems. It has many leaders such as Neal Ford, Mark Richards, Grady Booch and many other famous folks. This is further backed by SEI, IEEE and OMG. As of this writing there are reportedly 28 million developers in the world… how many of them talk about software architecture?
The software architecture narrative says that software whether it is built or customised is a very complex beast. It suggests software delivery is inherently more complicated than physical buildings, as its raw material are much more dynamic than buildings and thus software development is a craft and architecture is an art. It depends on rigorous engineering models and artefacts to understand multiple views of a piece of software to ensure it not only meets requirements for business concerns but also can be maintained over time in performant, resilient ways. This narrative assumes that leaders of development become architects as they mature in their understanding of advanced software development knowledge and skills.
The software architect narrative has a very strong value proposition as they are entrenched in delivery. This gives significant credibility in terms of outputs for the entire group and for software in general. This group retains its value through ups and downs and should be a source of continued identification in our profession.
For transparency, I come from the software architecture background though my career pushed me into the solution then organization change and innovation leader role below quite quickly.
Narrative Challenges
The objections to the the software architecture narrative are based on a few factors. One in its pure form it does not recognise business competencies and human dynamics as a fundamental part of the practice. This has led to huge difficulties in the space. For example, much of agilities success and failure stem from whether the software architect has these skills or whether there is one at all. A quote from a leader of the largest agile development transformation I have seen (25000 people)… “I cant make this work without twice the number of architects at the team level. Otherwise it just lands in chaos.” Certainly the opportunity in the software architecture narrative is to understand the relationship with engineering and architecture and how they work together to make more effective outcomes. But it is also to determine the right career path and skillset for the architect.
Right now this is based primarily on engineering skill as a differentiator. This too creates a conflict with senior developers as the architect title has mixed reception in developer communities. The developers often feel they should make decisions and not the architect so retaining credibility and pull with them becomes as important as making effective decisions. This belief system also creates another confusing outcome which is that architect is the natural evolution for a senior engineer. That is not the case in other fields where engineering and architecture are distinct disciplines with their own career paths.
The relationship with other architects is strained in the software narrative. The focus on delivery is often put down as ‘going native’ in other architecture circles. By being so technical they run the risk of being sidelined by other architects or business stakeholders as essentially ‘too technical’. In addition since their decision focus is quality attributes and technical tradeoff based it does not create the opportunity to evaluate decisions based on other more business focused outcomes. Overall, it appears that focusing this narrative more on business and human skills and creating an appropriate partnership with business architecture and transformation narratives has an amazing possible impact on the overall architecture practice.
IT Management and Planning
The ‘city planner’ narrative is focused on governance, large IT planning, big purchases and evaluation. This is the traditional Enterprise IT architecture narrative. It is primarily aligned with the CIO and the CTO in an organization. The enterprise architecture narrative is based on the notion of understanding current state in terms of all projects, all current applications, services and capabilities. This baseline is then compared against target state (by other architects) and a roadmap to change is managed. The group often leads the architecture review board as a major phase gate to approve the rollout of large changes which are led by other architects (most commonly solution architects).
The benefits of the traditional city planners and governance activities are generally related to cost, risk and process excellence. They resonate perfectly with large organizations who primarily roll out pre-packaged or SAAS software and where technology is not seen as a major source of business advantage. In addition, the repository of artifacts, patterns, principles and reference models is seen as valuable by any architecture group as it is one of our core needs in all types of architecture. This group also excels at interacting with IT management and executives. One vendor went so far as to call EAs the CIOs best friend. This group is also deeply involved in governance which becomes more and more important in safety or infrastructure critical technology outcomes.
Narrative Challenges
We hear a lot of objections to each of our narratives. The biggest objection to basing architecture on the traditional EA narrative is that it is not transformation focused. The ivory-tower analogy has stuck permanently in this space. The other architects in a practice are often quite vocal in their difficulty with top-down control concepts that are necessary in the enterprise architect mindset. There are not enough of them to cover all the places they need to be. Their skills atrophy and theirfore they lose the ability to critic others work. They often feel connected to their scope as if it is seniority or authority. That connection with ‘Enterprise’ or ‘Domain’ sometimes causes conflict especially if they have not personally delivered a solution or outcome in a long time. In addition the scope based titles seem to interact poorly with other leadership roles both in IT and business as there is not clear ownership.
Another type of challenge has emerged in the last ten to fifteen years. You can think of this as the ‘pure EA’ or ‘whole EA’ challenge. Effectively a group of practitioners and writers are regularly pointing to technology skilled EAs and calling them IT EAs and using that to minimize the value of those practitioners. This kind of challenge (which will likely show up in comments of this post) also challenges the primary realm of business architects and their relationship to busines strategy. Sadly the impact of this movement seems to be to create a very negative voice aimed at other architects instead of the unifying voice it could represent.
The stakeholder objections to the IT management approach are based primarily on a lack of alignment with business outcomes. Most EA groups are sponsored by the CIO or CTO and become aligned with the current state instead of the future state. The more they are aligned with change, the more they become like the innovation and transformation group below (this appears to be the ideal state).
The artifacts in EA are unclear. Not that there are not a few useful tools and techniques. A capability model… is that an EA artifact. If so how does it relate to business architects? Is the application portfolio an EA artifact? How does that relate to a CMDB? Who owns that when it is done? The size of a repository and the amount of data in it are often at odds with how agile they would like to be. In addition there is a possibility these tools will not be used by either stakeholders or architects who are more change focused.
The primary goal of the CIO focused agenda is most commonly cost savings, risk aversion and shared service focused. That is constantly at odds with a value outcome, risky and transformative agenda. How architects navigate that is key to creating this shared narrative.
Hard To Change and Expensive Technology
The big iron and big data architects have a very different narrative. It is one that is championed by the likes of Microsoft and Amazon for obvious reasons. This narrative is most common in infrastructure or cloud architects, though integration, data and engineering (operational technology) often land here as well. This includes people thinking about very expensive infrastructure and very large data storage and transformation. It is based on the notion that technology shifts like cloud and IoT are the most important aspects of technology and solutions are smaller changes on top of that. It is a very powerful narrative attached to very large dollar figures.
The basis for the infrastructure and information architecture specializations and narrative is that we need to look at the entire deployed technology landscape. It is based on very senior operations, data and engineering staff. It is based very much on quality attributes and procurement with the largest vendors in the ecosystem supporting it and generally comes from the relationship between data and infrastructure to the CIO. There is a reason many cloud architecture groups are not aligned with the EA or solution architecture practices.
There is significant value in continuously expanding architecture reach into infrastructure and data as they are our most strategic and expensive technical resources. Infrastructure and information architects are deeply credible with IT management and we cannot lose the link between technology investment and operational excellence.
Narrative Challenges
The objections to this narrative are generally similar to software architects or IT focused enterprise architects. It is difficult to find a transformation agenda in the infrastructure space. On average I hear challenges in becoming more business and human dynamic focused as well as searching for ways to separate engineering and architecture mindsets. Generally I hear the team itself complains that it lacks visibility into the business and demand planning sessions. In some respects it sees other architects as their primary stakeholders. Often there is no distinguishing the architects in this narrative from very senior engineers in their space. This creates the same kind of dissonance that exists when software architects are seen primarily as senior engineers.
Technology Innovation and Transformation
The final narrative I want to line up is the transformation and innovation space. This can also get the title Digital, Customer Engaged or other innovation based topics. This group of architects is heavily engaged with the solution space, from product innovation all the way up to change the business transformation. They are most often aligned with extremely senior solution architects who bypass both IT management jobs as well as enterprise architecture jobs in favor of larger and larger problem/solution domains.
This is the architect I became as a chief architect. My responsibilities often had direct board or CxO visibility and thus bypassed tradition IT management and EA hierarchies.
The transformation or solution narrative is one of our most powerful as it combines the benefits of three of our other narratives; business to execution, expensive to change and complex software. Think of them as hard core technologists who learned business skills, human dynamics skills and significant change management skills. This group of people have been heavily involved in digital transformation, digitally native business models, investment portfolios and outcome driven thinking. As a narrative goes it delivers real tangible value across many of the other narratives.
The transformation narrative works at almost all levels of scope. A software architect who begins to learn the people, business and change skills necessary can become a change agent. It works equally well for business architects who have technology skills. As a side note business architects with some deeper technical skill seems create massive advantage for the business and overall architecture practice. It works exceptionally well on a value stream basis and can be extended to include architects from the vendor and SI community.
The transformation agent is a darling of the business and executive team as well as the industry in general. They represent the reason that many if not most architects got into the field to begin with, to build cathedrals…
Narrative Challenges
The major objections to the transformation agenda are based in enterprise thinking. Effectively, change agents often ignore the current state (which they see as a positive position) and create significant change friction and potentially chaos. This is characterized by exponential sum, growth mindset individuals who can create more risk than the company has appetite. In addition more safety critical or non-technology differentiated business models can have severe cultural difficulties with this role. Often these approaches do not consider the full impact to current state and see each change as the most important instead of the overall health of the organization. There is a natural (and if handled well) inevitable tension between them and more big tech, big IT thinkers who tend to be more risk averse and command and control. In addition operational CIOs, CTOs and CFOs can be major blockers to the change agenda if change agents do not build effective bridges.
Conclusion
These narratives form the basis of our professional identities in more cases than not. I have eagerly studied the people and their descriptions of value for over 20 years to better understand them and to craft a profession that is inclusive of the value of all of them in a shared narrative while understanding that the more extreme examples of any particular narrative may not make it to the final profession. They are also the fundamental reason why I see long term architecture practices fail. EA teams get re-aligned or re-defined every 3-5 years. Software and solution architects are pushed out of agile transformations. Architects are kept out of strategy and planning sessions. And the stories go on and on. And yet I have seen the opposite occur when a practice takes hold and establishes a great shared narrative within their organization.