Solution Architecture- Learning to value change One of the keys to driving change in an organisation is recognising the need, or opportunity, for change and then to act (Grier, 2008). In order to act, a change agent is necessary – “a person from inside or outside the organisation who supports transformation by focusing on organisational effectiveness, improvement and development” (Grimsley, 2015). In situations where an organisation requires systems or software assets changes to accommodate environmental challenges, invariably the change agent is not in control of the change process due to the lack of specialised IT skills to deliver the change. This person is known as the “Sponsor” according to IT project management lexicon.Change is necessary to achieve and maintain business objectives. The question is, when designing software systems that must have lifespans of over 30 years, how do we architect solutions so they are never deemed legacy artefacts?

Software Architecture

Software architecture has over 150 definitions (Clements, et al., 2010). The Institute of Electrical and Electronics Engineers (IEEE) defines software architecture as the “fundamental organisation of a system embodied in its components, their relations to each other, and to the environment, and the principles guiding its design and evolution” (Clements, et al., 2010).As a measure of quality, an architectural solution needs to tick as many of the ‘-ity’ boxes as possible ¬– functionality, reliability, usability, efficiency, maintainability, and portability (Losavio, et al., 2003) – in order to be considered the best solution to implement.Curiously enough, an evaluation criterion valuing change is ominously missing from the ‘-ities’ outline above, and yet is referenced in many architectural documents as one of the major tenets of a well-architected software solution. It is clear to see that systems are created to solve visible and definable problems within the current bounds of knowledge, but we can’t build for problems we don’t yet know about.However, the current business landscape dictates that organisations must be ever-ready to adapt to change to respond to emerging needs that are not yet known. It is then imperative that software assets currently under construction embody the idea of change-readiness.

Traditional Approaches to Attaining Flexibility

Even though the value of change is not built into the core of software development in its current state, practitioners who bring these systems to life have tried to solve the problem of change in their own ways. However, much of the current innovation to better anticipate change has been driven by the pain incurred when delivering software projects, rather than for the sake of change itself.One such technique is soft-coding. Soft-coding uses a method of referencing values required to execute a particular piece of code in from an external source, such as a database, flat file or a web service call. Soft-coding is an alternative to hard-coding values in the source code. Developers can also implement the use of a configuration file to achieve faster responsiveness to change. However, the more complex the change within a domain is, the more it necessitates scripting. Scripting offers the control needed to implement such changes quickly and without a need for a product release. Lastly, vendors of off the shelf software may provide options for extensibility of a core product (such as extending a SAP implementation with ABAP code) which provide a degree of responsiveness to change.

Agile Approaches to Attaining Flexibility

Software practitioners have even gone to the extent of reviewing the process and methods of delivering software projects in the pursuit of finding better ways to deal with change. Software has traditionally been delivered through a waterfall process where each step of the cycle must be complete in order to proceed to the next step. In an Agile delivery approach, the steps of the development cycle are iterated multiple times in short and incremental cycles. By delivering smaller pieces instead of one large piece, change can be introduced into the system faster and thus outcomes are more aligned with the ever-changing environment. In essence, Agile is built on the odds that there will be change.By doing away with barriers to entry established by the waterfall process, Agile development has allowed a new breed of change-ready companies to enter and dominate the software industry. Companies such as Facebook, Twitter and Paypal are teeming with individuals who have the IT skill, and the ability to recognise the need and opportunity for change in their markets. The ability to be a change agent combined with IT skills has come about as a result of the fact that many of these change agents are the primary users of the products they develop. This closed feedback loop allows for change identification and responsiveness in a way that has not been seen before. The ultimate outcome is change-ready technology companies able to deliver product features and services at pace with the market change.

Valuing Change

Solution Architecture needs a radical paradigm shift above and beyond the tactics presented above in order to ensure software projects are change-ready. This must happen at the core of the discipline – at the ‘-ity’ level. The solution architecture discipline must embrace change by building it within it is core value set. In order to make this jump, solution architecture needs the backing of IT leaders who place a higher value on supporting business agility, rather than monitoring the effectiveness of traditional delivery mechanisms. Such a mind-set will enable IT as a whole to move to thinking about building software systems with change in mind.

To download a printable version of this story, click here.