Software Architecture in a Changing World

Software Architecture in a Changing World It is nearly 25 years since the seminal paper by Perry and Wolf [8] marked the recognition of software architecture as a recognisable discipline, and it has changed considerably over that time, from the basic problems of designing static software structures, to today’s global always-on, Internet connected systems with their ever evolving architectures. And the role of the software architect has continually evolved as well, to the point today where perhaps everyone is an architect? In this column we follow this evolution and ask what it can tell us about the future role of the software systems architect.

Five Ages of Software Systems When we look back over recent software history, we can see five identifiable evolutions of software systems, each one roughly aligning with a decade.

Figure 1 - The five ages of software systems

Through the 1980s, software systems were largely monolithic and tended to run on single computers, whether large central mainframes with terminals, or single user PCs. This was the era when software was developed as “programs” and architecture was largely a vendor concern, inherited from the platform that the software developers were using.

1 of 6

As we moved into the 1990s, distributed systems became mainstream, a lot of batch processing moved to online processing, and the standard style for an enterprise system became three-tier client server, with more architectural decisions to be made than before, but the architectural style still largely being dictated by vendors who supplied the development tools and system software in use. As the Internet became a mainstream technology in the late 1990s, organisations needed Internetconnected systems, which were “always on” rather than just “online”. These were initially websites but over time started to incorporate public user-interfaces for B2C and B2B business processing too. The architecture of these systems now had to support unpredictable and challenging non-functional qualities (particularly performance, scalability and security) and the main vendor concern during this period became supplying products that could meet these challenges (such as large scale servers and network load-balancers for scalability or firewalls for security). In our current era of the 2010s, the Internet has become a basic service and this has caused our systems to evolve again, from being “always-on” to being “used from anywhere for anything” as they are Internet-native systems where “the Internet is the system”. These systems are built from a combination of open source components, remote Internet connected services and custom code, and in turn, their services become part of the the Internet via publicly accessible APIs. These systems need public APIs (rather than just user interfaces), mobile UIs as their main user interface and to be based on flexible, adaptive architectural styles (notably microservices). The need to assemble systems from network accessible services and the use of cloud computing has moved us into an era where a primary vendor concern is supplying complete cloud-based application platforms, with many Internet-systems being deployed to PaaS platforms rather than traditional IT infrastructure. Following current trends, it seems that the next phase of evolution will be to Intelligent Connected systems, as artificial intelligence (machine learning in particular) becomes mainstream [2] and fast, reliable networks become ever more ubiquitous, allowing us to connect our “things” into systems as well as traditional computers [5]. These systems will move beyond providing “access anywhere” to providing “intelligent assistance” to their users. This is going to need a new architectural focus on data and algorithms as well as a move to “emergent” architecture which is only formed at runtime. This will be the era of “intelligence” becoming a primary vendor concern, as mainstream systems will use platforms which extend basic PaaS and IoT platforms with advanced services like packaged machine learning capabilities.

Five Ages of Software Architecture Software architecture has developed as a very pragmatic discipline and as the software industry has evolved through its different stages, the techniques and concerns of software architects have evolved in parallel, in response to the software engineering challenges that each stage has presented. We illustrate this with the simple diagram in Figure 2.

2 of 6

Monolithic

Modules, Information Hiding

Distributed

Views, Stakeholders, Styles, Assessment

Internet Connected

NFRs, Agility, Decisions

Internet Native

Evolution, Sustainability, Principles

Intelligent Connected

…?

Figure 2 - The evolution of software architecture During the period of monolithic systems development, software architecture had not been recognised as a discipline, but pioneers were already thinking about large scale software design, leading to structural design techniques like the use of modules for structuring large codebases and information hiding for encapsulating state and isolating change [7]. As technology moved to distributed systems, the increasing complexity of systems and their environments led to more complex design decision making, involving long-term trade offs. This led to software architecture being recognised as a discipline and the introduction of techniques to deal with this more complex environment, such as viewpoints and views for architectural description [10], explicit identification and management of stakeholders, the definition of proven and reusable architectural styles [4] and the introduction of architectural assessment techniques [3] to allow structured comparison of architectural options. Internet connected systems introduced further new challenges that resulted in a new architectural focus on their challenging non-functional qualities (or “quality properties”) and how to achieve them

3 of 6

[12], the importance of well-made, clearly-communicated architectural decisions [11], and how architectural design could support the agility needed to get change to market quickly [1] in order to respond to fast-moving Internet-driven markets. In our current era, Internet-native systems have resulted in further changes to the role of software architecture, as systems are now often much more malleable and dynamic, being composed from fine-grained network services (microservices). Systems are often built on PaaS platforms and so can be composed from a mix of platform services, network connected services from other suppliers and the system’s own unique services. This has meant that the software architect must be concerned with enabling rapid and reliable evolution of the system, that the architecture is sustainable over the long term (and will not ossify under a mountain of technical debt) and that the architecture is defined more as a set of patterns and principles rather than a static structure that remains stable for a long period. As we look to the future and Intelligent Connected systems become the norm, how will the role of the software architect change again?

The Future of Software Architecture One thing we can see from the past is that as the nature of systems changes, so does the practice of software architecture. The next set of trends that seem likely to cause this as we move to Intelligent-Connected systems are listed in Table 1. Let us explore each one in a little more detail.

Less

More

Structural Design

Data and Algorithm Design

Defined Structure

Emergent Runtime Structure

Decisions

Principles, Policies and Algorithms

Certainty

Probability

Operational Process

Operational Policy and Automation

Capex

Opex Table 1 - Trends in Software Architecture

While structural design isn’t going to go away, the need to integrate dynamic architecture and intelligence into systems is going to push us to reconsider how important data and algorithms are. These are topics that don’t appear prominently in software architecture literature as it is often felt that they can be encapsulated within system elements rather than being system-wide concerns (e.g. the original 4+1 viewpoint set [6] had no data or information view). However when a system needs to be dynamic and intelligent, they become important system-wide architectural concerns. Another trend that seems very likely is a move from structure being defined “up front” through an architectural design process, to the definition of architectural structure formed at runtime by

4 of 6

combining a large number of network services to form a system. It’s worth noting that this is quite different to the sort of “emergent architecture” which some Agile practitioners talk about - they’re talking about conventional “static” architecture, which is developed incrementally as a project progresses (and more information becomes available). This trend is towards architectural structure that is only apparent at runtime due to dynamic composition of services. A fairly recent evolution in software practice has seen the architect acting less as an “up-front” designer of structures, and becoming responsible for a stream of informed, significant decisions, made just in time for the project [9]. However even this fairly recent practice is likely to be affected by the challenges of intelligent-connected systems. While structural decisions will still be important, dynamic systems like these require much more focus on principles to guide their structure and evolution, policies that control runtime behaviour and in some cases, even algorithms that govern the dynamic evolution of a system. The combination of these factors means that software architects will need to deal much more with probability rather than certainty (or an assumption of certainty). Factors such as composing systems from 3rd party services, the use of machine learning and analytics in system design, integrating very large numbers of small (IoT) devices and the use of dynamic runtime environments such as PaaS platforms all imply that architecture will involve dealing with statistical characteristics and trends more than statically defined structures and definite quantities. The operational aspects of our systems are going to evolve too, which will also affect architecture practice. Whereas today architects may well be involved in defining and advising on operational processes, large dynamic systems will require policy-driven automation rather than today’s carefully designed step-by-step processes (whether or automated or manual). Finally, while finance and budgeting aren’t usually seen as part of architecture work, architecture is very much the “art of the possible” and so financial constraints can limit or enable architectural decisions. As we move towards cloud hosted systems, usage based pricing for both platform and services, and systems that are policy driven (rather than statically defined) this will push our financial models and budgets from capital expenditure biased (capex) to operational expenditure biased (opex). The implications of this on an organisation’s Finance group may well involve architects having many more conversations with accountants that we are used to!

Conclusion As software systems have evolved, so has software architecture, with each era of architecture practice evolving to meet the changing challenges of software practice at that time. This has successfully led software architects from basic concepts like information hiding, through the foundation of the discipline to techniques like viewpoints and architectural assessment which are mainstream today. More recently architecture practice has evolved further to the point where architecture has become an implicit part of mainstream practice and is often seen as an activity rather than a distinct role, focusing more on decisions and principles than the previous focus on defining structure. The next phase of software evolution looks even more radical with intelligence, dynamic composition, cloud platform deployment and the connection of “things” to mainstream systems

5 of 6

presenting a new set of challenges that will require yet another evolution of architecture practice. We can only predict what this will look like, but it’s certainly going to be an exciting and absorbing ride. What a great time to be a software architect!

References 1. P. Abrahamsson, M. Babar, and P. Kruchten, “Agility and Architecture: Can They Coexist?,” IEEE Softw. IEEE Software, vol. 27, no. 2, pp. 16–22, 2010. 2. “Amazon Machine Learning - Predictive Analytics with AWS,” Amazon Web Services, Inc. [Online]. Available: https://aws.amazon.com/machine-learning/. [Accessed: 19-Aug-2016]. 3. P. Clements, R. Kazman, and M. Klein, Evaluating software architectures: methods and case studies. Boston: Addison-Wesley, 2002. 4. D. Garlan and M. Shaw, An introduction to software architecture. Pittsburgh, PA: School of Computer Science, Carnegie Mellon University, 1994. 5. G. Kortuem, F. Kawsar, V. Sundramoorthy, and D. Fitton, “Smart objects as building blocks for the Internet of things,” IEEE Internet Computing IEEE Internet Comput., vol. 14, no. 1, pp. 44–51, 2010. 6. P. Kruchten, “The 4 1 View Model of architecture,” IEEE Softw. IEEE Software, vol. 12, no. 6, pp. 42–50, 1995. 7. D. L. Parnas, “On the criteria to be used in decomposing systems into modules,” Communications of the ACM Commun. ACM, vol. 15, no. 12, pp. 1053–1058, Jan. 1972. 8. D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” SIGSOFT Softw. Eng. Notes ACM SIGSOFT Software Engineering Notes, vol. 17, no. 4, pp. 40–52, Jan. 1992. 9. E. R. Poort, “Driving Agile Architecting with Cost and Risk,” IEEE Softw. IEEE Software, vol. 31, no. 5, pp. 20–23, 2014. 10. Systems and software engineering: architecture and description = Ingénierie des systèmes et du logiciels: description architecturale. Geneva, Switzerland: ISO/IEC/IEEE, 2011. 11. J. Tyree and A. Akerman, “Architecture Decisions: Demystifying Architecture,” IEEE Softw. IEEE Software, vol. 22, no. 2, pp. 19–27, 2005. 12. E. Woods and N. Rozanski, “Using Architectural Perspectives,” 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05).

6 of 6