I think defining 'architecture' is a good place to start with this topic. Good old Wikipedia has two definitions. The second one suits my purposes better and that is that architecture is the complex or carefully designed structure of something − I would add to that definition 'by using tools'. This is where continuous architecture comes into the picture.
One academic paper notes that current trends in the technology industry include a move away from traditional enterprise architecture due to the need for a design approach that encompasses continuous delivery, thereby providing it with a broader architectural perspective.
This approach is 'continuous architecture', and it is about using the appropriate tools to make the right decisions and support continuous: delivery, integration and testing. These academics see continuous architecture as an approach based on a toolbox and not a formal process.
As far back as 2017, Forrester noted that continuous architecture plugs the gap between planning and delivery. Moreover, enterprise architecture professionals need to redefine their approach to continuously deliver value.
According to Forrester, customer obsession is driving firms to add agility into their planning-to-optimisation of value stream processes. It notes that unlike their peers on portfolio management and agile development and operations (DevOps) teams, enterprise architecture (EA) professionals have been slow to adapt their role to support business agility. They say many EA pros have looked purely at their role in agile project delivery, while others have explored EA's role in a continuous delivery environment.
What I find interesting is that everything is 'continuous' due to the new agile way of working, which is augmented by digital transformation at the speed of COVID − where architectures are being created on an ongoing basis.
However, they are also becoming increasingly complex as every time there is a change in business requirements − POPIA would be one example, or new services, or billings, etc, are introduced − these developments influence continuous architecture but really it might more aptly be defined as 'designing for the future'.
I would like to develop the differences between traditional enterprise and continuous architectures and why the latter is needed today.
Enterprise/solution and continuous architecture
Enterprise architecture is regarded as satisfying the growing demand to reduce costs, increase flexibility and regulate technology environments. It can be divided into different architectural layers that involve business architecture and IT architecture (data, application and technology architecture).
The first principle of continuous architecture is the drive to architect/design products and not just solutions for projects.
Solution architecture takes a problem and proposes building blocks to solve it. It often reuses other elements made available by the enterprise architecture.
The first principle of continuous architecture is the drive to architect/design products and not just solutions for projects. This is founded on the fact that projects rarely exist in isolation − they are often part of a software product − which is a concept that drives a different way of thinking about how software is delivered. Apps need to be thought of as virtually a commercial software factory.
The Gartner 2020 Building Digital Platforms Study shows that application architecture skills, including cloud-native, agile/DevOps, API mediation, multi-experience and event-driven architectures, are closely linked to digital business success. This is a significant statement from the one of the world's leading analyst corporations.
It notes that developing architectural skills is complex and time-consuming and that in many cases organisations that don't do so miss out on the benefits of digital transformation and digital business.
Gartner advises on how to improve application architecture skills in organisations with a set of key steps it has identified, and these include prioritising learning and development of architectural skills that have the most organisational impact, plus detecting impediments to the growth of these skills. Creating a learning climate with routine learning opportunities and methods is also encouraged.
Let's look at product management which can be defined as a focus on stakeholders, not on plans or budgets.
What is product management?
The concept of product management has been in the industry for decades. It focuses on the success of introducing and maintaining a thriving commercial product for an organisation.
It can also be described as taking ownership of a product from concept through to withdrawal. It is without doubt an essential business discipline, whereby the product manager may be likened to a conductor in an orchestra − without the latter, mayhem can ensue as each instrument fights to be heard in a continuous cycle of disarray.
Let's define what this means for IT.
Very few IT organisations value the role of a product manager − that needs to change. The first step is to clearly define the role and give it teeth. The product manager is a peer of the IT owner. What needs to happen is that this role must be viewed as a valuable asset within the IT organisation.
Fill or kill?
A governance model needs to be implemented whereby all products are reviewed periodically and it is determined either to provide them with additional/continued budget, which can be referred to as fill, or to stop the investment and wind down − kill.
Then, of course, the commercial aspect for IT needs to be considered − this is certainly not around producing profit but is rather the ability to justify its cost basis.
The foregoing should be enough to get you to realise the importance of elevating product management to first-class citizenship in your organisation. In doing so, you will have implemented the first principle of continuous architecture.
In my next article on continuous architecture, I will reveal how important it is to focus on quality attributes and not on functional requirements.
Share