By Paddy Fagan, STSM IBM Watson Health
I work on a team delivering updates to an existing SaaS application, in the health & human services space. In doing this we need to support our existing customers/use cases, expand the use cases supported, and evolve the architecture to support both, and the evolving landscape of the PaaS, in our case IBM Cloud, which hosts the application.
In our approach we implement many of the Open Agile Architecture practices. Here, I’m going to focus on continuous architectural refactoring, particularly planning, understanding and guiding the architecture. As we evolve our solution we need to balance the drive to improve the function/feature for customers, keeping pace with the evolution of the PaaS and maintaining/improving the non-functional characteristics of our solution.
In terms of planning it’s key to have a ‘vision’ for the evolution of the architecture, this is not something that is set in stone, but rather a best estimate of where the architecture should be heading based your current knowledge. This can and will change as external factors shift and influence your architecture. However, notwithstanding the volatility of the ‘vision’, it remains a central tool in guiding the evolution of the architecture, as it acts a reference point to assess proposed architectural changes against, to determine if they are moving the architecture as a whole towards your goals.
On my teams, this ‘vision’ tends to be a backlog of sorts, listing the set architectural changes that we feel we ultimately need to make. One key element of the value in this to us is that it allows us to quickly see where a proposed change intersects with this list – and that can inform our decision making. Sometimes, this causes us to change the ‘vision’ and indeed sometimes we allow change that takes us further away from the ‘vision’ – but at every point these are informed decisions.
In many ways the ‘vision’ is also a key constraint in understanding and guiding the architecture, but there are others. For my teams, hosting and operations costs are always a highly important consideration – in short if our solution isn’t profitable we won’t be in business for long! The other key constraint for us is compliance, our offerings are in heavily regulated areas, and so often architectural change is constrained by this. Questions like: “Is the service we want to consume available in a compliant version?”, “Can our solution as whole continue to meet the compliance standards with this change?” – often dominate our thinking. The other key aspects of understanding and guiding the architecture that I want to cover are the things we give the developers/teams to help them stay within the overall constraints of the architecture as they design and implement changes. Some of these are “Fitness Functions”, executable verification of characteristics of the architecture, some are “Guardrails” written statements of the characteristics. One constant pressure in this is to try to find ways to encode as many of the characteristics as possible as “Fitness Functions” – in order to reduce the number of things the developers and teams have to actively consider as they proceed.
Paddy Fagan is an expert in the architecture and design of enterprise business applications. Working across SaaS & on premise solutions in healthcare and government. He is also an occasional cyclist and teacher, and a dad. Paddy is known as an essential technical leader. Paddy has a wealth of experience working with key initiatives and customers delivering best of breed solutions to meet strategic business needs, including Health Care reform (ObamaCare) deployments and key enterprise customers.