Continuous Architecture

Sustainable Architecture in an Agile and Cloud-Centric World

Murat Erder, Pierre Pureur

• Publisher: Morgan Kaufmann
• Year: 2015
• ISBN:
  9780128032855
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Continuous Architecture provides a broad architectural perspective for continuous delivery, and describes a new architectural approach that supports and enables it. As the pace of innovation and software releases increases, IT departments are tasked to deliver value quickly and inexpensively to their business partners. With a focus on getting software into end-users hands faster, the ultimate goal of daily software updates is in sight to allow teams to ensure that they can release every change to the system simply and efficiently. This book presents an architectural approach to support modern application delivery methods and provide a broader architectural perspective, taking architectural concerns into account when deploying agile or continuous delivery approaches. The authors explain how to solve the challenges of implementing continuous delivery at the project and enterprise level, and the impact on IT processes including application testing, software deployment and software architecture.

• Covering the application of enterprise and software architecture concepts to the Agile and Continuous Delivery models
• Explains how to create an architecture that can evolve with applications
• Incorporates techniques including refactoring, architectural analysis, testing, and feedback-driven development
• Provides insight into incorporating modern software development when structuring teams and organizations

Chapter 1

Introduction to Continuous Architecture

Abstract

Through our careers, we have noticed the increasing speed of delivery expected from information technology practitioners within enterprises. At the same time, the ease of use and 24/7 expectations of end users are driven by the overwhelming expansion of technology in our daily lives—we have progressed from PCs to tablets to smartphones to wearable technology. Today software delivery teams are expected to operate on an Internet time and scale. This has significantly increased the demand and resulted in the widening adoption of Agile and Continuous Delivery practices. As a result, the pendulum has swung away from traditional software architecture practices and in particular Enterprise Architecture. We do not believe that the pendulum will swing back to these traditional practices. However, there is still a need for an architectural approach that can encompass Continuous Delivery, providing it with a broader architectural perspective. This is the main topic addressed in this book.

Keywords

Continuous Architecture principles; Continuous Delivery; Agile development; requirements; Quality Function Deployment (QFD); Quality Attributes; Architecture Tradeoff Analysis Method utility tree; architecture and design decisions; loose coupling; microservices; Conway’s law; minimum viable product; Minimum Viable Architecture; legacy monolithic systems; continuous feedback

“We are called to be architects of the future, not its victims.

—R. Buckminster Fuller

Both of us call ourselves architects because we believe there is no better explanation of what we do every day at work. Through our careers covering software and hardware vendors, management consultancy firms, and large financial institutions, we have predominantly done work that can be labeled as software, solution, and enterprise architecture.

However, when we say we are architects, we always have a need to qualify it; we believe an explanation is required to separate ourselves from the stereotype of an IT architect that adds no value. Most readers are probably familiar with the common expression of: “I am an architect, but I deliver/write code/engage with clients” (fill in with your choice of an activity that is perceived as valuable).

How has this notion of the ivory tower architect become so predominant? We are confident that we are not alone in this mindset. We also believe that architects who exhibit the infamous qualities of abstract mad scientists, technology tinkerers, or presentation junkies are a minority of practitioners. A majority of architects work effectively as part of software delivery teams, most of the time probably not even calling themselves architects. In essence, all software has an architecture, and most software products have a small set of senior developers who create a consistent architecture regardless of whether it is documented or not.

Through our careers, we have also noticed the increasing speed of delivery expected from IT practitioners within enterprises. At the same time, the ease of use and 24/7 expectations of end users are driven by the overwhelming expansion of technology in our daily lives—we have progressed from PCs to tablets to smartphones to wearable technology. Today software delivery teams are expected to operate on an Internet time and scale. This has significantly increased the demand for and resulted in the widening adoption of Agile and Continuous Delivery practices.

As a result, the pendulum has swung away from traditional software architecture practices and in particular Enterprise Architecture. We do not believe that the pendulum will swing back to these traditional practices. However, there is still a need for an architectural approach that can encompass Continuous Delivery, providing it with a broader architectural perspective. This is the main topic addressed in this book. Before we define Continuous Architecture, let us first provide a definition of software architecture and then consider the historical perspective.

What Do We Mean by Architecture?

When we talk about architecture, we are concerned with software architecture. How do we define software architecture? Let us look at a few common definitions.

According to the Wikipedia entry maintained by IFIP WG 2.10¹ on software architecture:

Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building.

The International Standards Organization and Institute of Electrical and Electronics Engineers (IEEE) use the following definition*:

Architecture: the fundamental concepts or properties of a system in its environment embodied in its elements, their relationships, and in the principles of its design and evolution.

Specifically, we are dealing in this book with the IT concerns of software development within a commercial enterprise.

The four most common reasons for developing a software architecture are to:

1. Define the guiding principles and standards. Architecture is a vision of the future, and supporting tools to help you get there.

2. Develop architecture models. In this case, architecture is concerned with abstracting at an appropriate level to make business and technical decisions.

3. Build common services. The services could be systems or organizations. Architecture can be defined as focusing on defining interfaces.

4. Create a roadmap to an IT future state. Architecture deals with transition planning activities that lead to the successful implementation of an IT blueprint.

In accordance with these goals, building a large software system in an effective and efficient manner requires a blueprint—commonly referred to as a “software architecture.” Such an architecture includes descriptive models (defined in both business and technology terms) to aid decision makers in understanding how the entity operates today and how it wants to operate in the future and prescriptive models to help the project team successfully transition to its desired IT state.

Historical Perspective

Let’s look at a brief history of the evolution of the computer and software industry. Our objective here is not to provide a comprehensive history but highlight a few key developments to put Continuous Architecture in a historical perspective.

While looking at the history of computer technology, it is interesting to look at two aspects, the major technology “epochs” versus concepts evolving in software development and software architecture. We can articulate the major epochs in the computer industry as:

1. The age of the mainframe (1950s +): This started basically in the 1950s with the main computing paradigm being mainframe computers. These were expensive and powerful machines that enabled large corporations to start automating certain aspects of their businesses as well as supporting scientific development.

2. Getting personal (1970s +): This is when PCs (Personal Computers) as we know them today were introduced. It was a huge leap forward in the sense that computing power could be put in one machine that could sit on a desk. This enabled individuals to interact with computers in a much more “personal” manner. However, most individual users of such technology were still in large companies and research institutions.

3. Distributing the load (1980s +): As computers evolved in capacity and started becoming networked, the concept of client server architecture started evolving. This resulted in a view that not all software needed to run on a single computer but that the computing burden could be shared. At that time, client server architecture and how best to distribute responsibilities were major architectural topics. As the client server paradigm evolved, so did the concept of networked computers.

4. Era of connectivity (1990s +): The “network is the computer” term was coined in 1984 (the term is attributed to John Gage, Chief Researcher and fifth employee of Sun Microsystems), but it took another 10 years before the first commercial browser was introduced (The Mosaic browser was released in November 1993). The World Wide Web and Internet revolution has had tremendous impact on not only the software industry but also the entire world. We do not have sufficient space to detail its impact, but needless to say that everything has changed from the way we shop to the way we communicate and even to how our gadgets interact.

5. Back to the future (2000s +): With the ubiquitous Internet came the opportunity to unleash us from dependency on physical devices. The ability to store and retrieve information from the cloud creates even further opportunities, as well as challenges.
For example, we do not always physically own the books we buy on our e-readers.² The company that sells us the books is the owner of the content and has the right to remove it, which would not be an option for old physical books. We will leave the ethical discussion of the Internet and cloud computing to other authors and go back to our architecture storyline.
The cloud era has also enabled enterprises to only acquire the required software and compute capacity. We call this era “back to the future” because we are back to the model of leasing capacity, which was exactly the model in the mainframe days. The only difference is that we are implementing the model in a highly interconnected, standardized, and real-time world.

The computer and software world will continue to evolve, with the next phase currently coming from mobile devices and wearable computers. What has not changed during this approximately half a century journey is the fact that developers still write code. What is also interesting is that productivity among developers is still quite varied, and creativity is still associated with the developer role. Basically, we still are in a software as a craft stage and have not been able to fulfill the industrial revolution and automation that have been promised at each stage in the journey.

What has changed, though, is the speed at which we are expected to execute, as well as the scale in which we need to operate. Quarterly release cycles are no longer relevant, and commercial solutions have to cater to increasing demands from end users in terms of performance, usability, and scalability.

Figure 1.1 highlights some interesting data points in the five epochs we have listed in the brie...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Foreword by Kurt Bittner
• Foreword by Peter Eeles
• Acknowledgments
• Chapter 1. Introduction to Continuous Architecture
• Chapter 2. Principles of Continuous Architecture
• Chapter 3. Getting Started with Continuous Architecture: Requirements Management
• Chapter 4. Evolving the Architecture
• Chapter 5. Continuous Architecture and Continuous Delivery
• Chapter 6. Validating the Architecture
• Chapter 7. Continuous Architecture in Practice: A Case Study
• Chapter 8. Role of the Architect
• Chapter 9. Continuous Architecture in the Enterprise
• Chapter 10. What About Enterprise Services?
• Chapter 11. Conclusion
• Glossary
• Index