Role of the Architect

 

The role of the architect is widely accepted in the world of technology, but not clearly defined.  This blog post provides a summary of the views we expressed in our book[i] as well as in an article published in IEEE Software[ii].

In general, the term architect exemplifies individuals who make key decisions about the structure and behavior of a system – be that software or other technology areas. Though software architect is the most commonly used term, there are network architects, storage architects, information and security architects. You could even say that any technology subject area has people that identify themselves as architects.

All these types of architects appear to share the following characteristics:

• Architects have deep knowledge in the domain of interest.
• They mostly do not directly implement (some architects can create executable prototypes during architecture sprints or runways), instead dealing with higher levels of abstraction by defining the structure of a system in the domain of interest.
• They have explicitly or implicitly the authority of making decisions in the domain of interest

In his book Mythical Man-Month[iii] Frederick Brooks talks about the conceptual integrity of a software product. This is a good place to start for defining the role of the architect – basically they are accountable for the ‘conceptual integrity’ of the entity that is being architected.

Architects deal with a higher level of abstraction than implementers, developers or engineers, do. Their concerns include the main components of the system and how they interface and they continuously validate the architecture against different scenarios. They need the ability to traverse different levels of abstraction between concepts, models and implementation details.

The role of the architect in agile development is hotly debated in the industry. Some Agile practitioners believe that there is no need for an overall architecture, since the architecture “emerges” through the implementation of stories and refactoring. We believe that such a view applies only to simple and fairly self-contained projects. If you are architecting a product or try to operate at a large scale you do need to think of the architecture – however, this does not mean that you need a separate architect, but the role of the architect is still crucial to success.

We recommend three focus areas for defining the role: Unit of Work, Product Focus and the Realized Architecture.

Unit of Work

An interesting way of considering architect role is to focus on their key activities. In other words, what is the key unit of work of an architect? Is it a fancy diagram, a logical model, a running prototype? We believe that the basic unit of work for an architect is an architectural decision. As a result, the most important output of any architectural activity is the set of decisions made along the software development journey. Surprisingly, little effort is spent in most organizations on arriving at and documenting architectural decisions in a consistent and understandable manner.

We can state that, the key responsibility of an architect is to drive architectural decisions to a conclusion.

We purposely used the term drive to a conclusion rather than make. The term drive to a conclusion implies that the architect engages with stakeholders and works through the options to arrive at a decision. It does not mean that an architect can abdicate responsibility for making sure that architectural decisions are made. An architect must make sure that decisions are made in a timely manner.

Product Focus

As explained in our book, we believe that architects should focus on architecting products, not just solutions for stand-alone projects. It follows that the architect should operate as part of a team – in this case a product team. This implies that communication and collaboration skills become highly relevant.

Within the context of a single product, the architect plays a key role in the product team. Her/his main responsibility is to balance the demand from the client as represented by the product manager, with the delivery focus provided by the product delivery manager. The architect has to make sure that the architecture of the product is coherent and sustainable. Especially in the initial phases of a product life cycle, there is often a “negotiation” between product management and the “art of the possible”. Managing this conversation is a key responsibility of the architect.

Realized Architecture

The real architecture of a system is represented by the code that is running on the physical infrastructure. We will call this the “realized architecture.”We believe that the days of an architecture only represented as a set of documents are over.

The role of the architect is to understand, influence, improve and communicate the Realized Architecture.

Therefore, it is important for an architect to understand the code running on the physical architecture.

Final Definition

We can summarize our views by defining the role of the architect as:

An architect is responsible for enabling the implementation of a software product by driving architectural decisions in a manner that protects the conceptual integrity of the software product.

 

 

[i] M. Erder and P. Pureur, Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World, Morgan Kaufman, 2015

[ii] M. Erder and P. Pureur, What’s the Architects Role in an  Agile, Cloud-Centric World, IEEE Software Vol 33, No 5, pp. 30-33

[iii] Brooks, Frederic, 1975 & 1995, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, ISBN 0-201-00650-2 (1975 ed.), 0-201-83595-9 (1995 ed.)

Advertisements

Delaying Decisions in Continuous Architecture

Delaying Design Decisions Yields Better Results!

In the previous installment of our “Continuous Architecture” blog as well as in our book, we discussed how to effectively capture requirements.

The second Principle of Continuous Architecture provides us with guidance to make architectural and design decisions to satisfy quality attribute requirements, and not to focus exclusively on functional requirements. Functional requirements often change frequently, especially if we are architecting one of those “Systems of Engagement” delivered over a mobile device whose user interface is likely to change frequently in response to changing customer needs, competitive response, and ever-evolving mobile technology.

Even quality attribute requirements are subject to change, or at least to underestimation. When a mobile or web application’s popularity goes “viral”, even the most carefully crafted applications can collapse under the unexpected load. In addition, performance and availability targets may be vaguely described as Service Levels Agreements (SLA’s) or Objectives (SLO’s) are not always clear. A common practice is to err on the side of conservatism when describing those objectives which may result in unrealistic requirements.

We recommend making design decisions based on known facts – not guesses. In our book and elsewhere in this blog, we describe how to leverage a Six-Sigma technique (Quality Function Deployment or QFD for short) to make sound architecture and design decisions. One of the advantages of the QFD process is that it encourages architects to document the rationale behind architecture and design decisions and to base decisions on facts, not fiction.

An interesting parallel can be made between the principle of delaying design decisions and a technique called simulated annealing which is a probabilistic technique used for solving optimization problems.

Image processing is one area where this technique is used.  Basically if you want to clean up a noisy image, instead of applying a deterministic model you iterate over the image thousands of times. At each iteration you make a decision for a particular pixel based on the value of its neighbors. The interesting part is that in the early iterations you allow a high value of uncertainty in that decision – i.e. you make a probabilistic guess. As iterations evolve you restrict the uncertainty, of the probabilistic jump. So the image cools down, just like steel cooling down when you anneal it – hence the simulated annealing term.

How does this relate to architectural decisions? Simply put if you cool down the image too quickly it cracks – just like steel cracking if you cool it down too quickly. The same concept applies for architectural decisions, if you make too many decisions early on in the process your architecture will fracture.

Below is a picture of a simulated annealing example, showing results of two parameter sets used in the algorithm (bottom left and bottom right quadrants)

As we move away from waterfall application development lifecycles involving large requirement documents and evolve toward the rapid delivery of a viable product, we need to create Minimum Viable Architectures (MVAs) to support the rapid delivery of those products. This concept is discussed in more details in Chapter 7 of our book and in one of our blog entries.

To that effect, limiting the budget spent on architecting is a good thing; it forces the team to think in terms of a Minimum Viable Architecture that starts small and is only expanded when absolutely necessary. Too often, a team will solve problems that don’t exist, and yet fail to anticipate a crippling challenge that kills the application. Getting to an executable architecture quickly, and then evolving it, is essential for modern applications.

 

Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

Requirements in Continuous Architecture: Let’s Clarify!

Clarifying Requirements is Important

In the previous installment of our “Continuous Architecture” blog as well as in our book, we discussed an effective approach for capturing requirements. We suggested that thinking in terms of testable hypotheses instead of traditional requirements enables teams following the Continuous Architecture approach to quickly deliver systems that evolve in response to users’ feedback and meet or even exceed users’ expectations. But are we sure that we always understand what the system stakeholders want, even when they are able to precisely quantify those requirements?

Philippe Kruchten tells the following story about the importance of clarifying requirements. Back in 1992, Philippe was leading the Architecture team for the Canadian Air Traffic Control System (CAATS), and the team had a requirement of “125 ms time to process a new position message from the Radar Processing System, from its arrival entry in the Area Control Center till all displays are up-to-date”.

Here is how Philippe tells the story: “After trying very hard to meet the 125 ms for several months, I was hiking one day, looking at a secondary radar slowly rotating (I think it was the one on the top of Mount Parke on Mayne island, just across from Vancouver Airport). I thought … “mmm, there is already a 12-20 second lag in the position of the plane, why would they bother with 125ms…?”

Note: primary radar uses an echo of an object. Secondary radar sends a message “who are you?” and the aircraft respond automatically with its ID and its altitude (http://en.wikipedia.org/wiki/Secondary_surveillance_radar). It looks like this: https://www.youtube.com/watch?v=Z0mpzIBWVG

I knew all this because I am myself a pilot…

Then I thought:  “in 125ms, how far across the screen can an aircraft go, assuming a supersonic jet… and full magnification”. Some back of the envelope computation gave me…about 1/2 pixel! When I had located the author of the requirement, he told me: “mmm, I allocated 15 seconds to the radar itself (rotation), 1 second for the radar processing system, 4 seconds for transmission, through various microwave equipment, that left 1 second in the ACC, breaking this down between all equipment in there, router, front end, etc.., it left 125ms for your processing, guys, updating and displaying the position…” These may not have been his exact words as this happened a long time ago, but this was the general line… Before agile methodologies made it a “standard”, it was useful for the architects to have direct access to the customer, often on site… And in this case being able to speak the same language (French)”.

Philippe’s story clearly stresses that it is important for an Architect to question everything, and not to assume that requirements as stated are absolute.

 

Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

Continuous Architecture and Requirements

Source: Continuous Architecture and Requirements

Continuous Architecture and Requirements

Don’t Think Functional Requirements, Think Faster Time to Feedback

As we discussed in Chapter 1 of the “Continuous Architecture” book and elsewhere in this blog, capturing and managing requirements accurately and timely  – especially Quality Attribute Requirements – is an essential part of the Continuous Architecture approach. Traditionally, the approach to capturing and managing requirements has been based on conducting interviews of subject matter experts (SMEs) in order to document  requirements that the system must satisfy, often documented in voluminous documents which are hard to read and analyze. Ideally, the interviewees should be actual or prospective users of the system being developed, but in practice the interviewers often have to settle for representatives from the business who believe that they are familiar with the way the system is (or will be) used.

Collecting requirements from user representatives who attempt to guess the needs of real users as well as the best ways to satisfy those needs often result in systems that fall short of real users’  expectations. In addition there is often a significant time interval between the interviews and the delivery of the system, and this may lead to further disappointment as requirements  may change due to evolving business conditions.

As Forrester Research Principal Analyst Kurt Bittner states, “The problem is the SME paradigm itself. No one person can represent the needs of all users, no matter how hard they try. The problem goes deeper: The conscious mind often cannot express what is really needed, and only knows what it doesn’t like when it sees it. As a result, the surest path to success is to put something out there that minimally satisfies some need, sometimes called a minimum viable product, and then improve upon that in rapid cycles.”

The objective of the Continuous Architecture approach is to enable the rapid delivery of a minimum viable product that may be designed to satisfy some need or validate some hypothesis, and will continuously evolve as feedback from the users is received. As we describe in the book and in this blog, we achieve this objective by creating a “minimum viable architecture” that also continuously evolve as user feedback is received, and enables the delivery of a system that meets or even exceeds its users’ expectations.

Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture.

When Should Continuous Architecture Be Used?

Source: When Should Continuous Architecture Be Used?

When Should Continuous Architecture Be Used?

With respect to release cycles and deployment mechanisms, modern architectures may need to function at multiple speeds. An IT organization is going to have a “portfolio” of applications, some of which can support high rates of change (due to their loosely coupled architectures), and some of which cannot be released very fast because they are tightly coupled and therefore tend to be brittle.

A “Continuous Architecture approach” takes this into account and is able to deal with different release rates. For example, Systems of engagement (especially mobile and cloud applications) lend themselves to a Continuous Delivery approach. Systems of Record and Systems of Operation are usually not a good fit for Continuous Delivery as traditional tightly-coupled architectures often require substantial rewrites in order to keep pace with evolving business needs and enhancements are often postponed until the need becomes critical.

As we discussed in an earlier post, Continuous Architecture is not a formal methodology. We think of it as an approach to adapt formal architecture thinking and discipline to an ever changing and evolving world. Our approach is driven by six simple principles (see figure below) and supporting tools.

As we describe in our book as part of our discussion of Principle 4 (Architect for Change – Leverage “The Power of Small”), loosely coupled architectures enable rapid changes and provide a significant advantage when “future-proofing” architectures.  However very few projects have the luxury of starting from a blank slate, and frequently architects have to deal with legacy, monolithic systems which often contain tightly coupled components. Uncoupling monolithic architectures is often a significant challenge but not an impossible one, and we offer some techniques in our book to deal with this challenge.

Using a Continuous Delivery approach, IT teams can rapidly and safely implement new requirements from the business by creating a regular, controlled, and highly automated delivery pipeline. Using that approach, an IT organization is able to move from a traditional model where business partners specify requirements to one where they switch to “testable hypothesis”. This in turn creates a new, high-speed IT function that sits alongside the legacy IT function. Using this approach, the high-speed IT function can focus on the systems of engagement for a few business areas, and provide a lot of value to the business. However we believe that the Continuous Architecture approach isn’t limited to Agile and Continuous Delivery projects. We have used it on projects using iterative and even waterfall methodologies, and it produces excellent results!

Please check other entries in this blog and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

Applying Continuous Architecture in Practice

Source: Applying Continuous Architecture in Practice

Applying Continuous Architecture in Practice

 

Continuous Architecture is a set of principles and supporting tools.

We do not aim to define a detailed architecture methodology or development process. Our main objective is to share a set of core principles and tools we have seen work in real-life practice. So applying Continuous Architecture is really about understanding the principles and applying them to the context of your environment. While doing this you can also decide about the tools you would want to recommend.

We are responding to the current challenge of creating a solid architectural foundation in the world of agile and Continuous Delivery. However, that does not mean that applying Continuous Delivery is a prerequisite for adopting the Continuous Architecture approach. We realize that some companies may not be ready to adapt agile methodologies. Moreover, even if a company if fully committed to agile methodologies, there may be situations such as working with a third party software package where other approaches such as Iterative or incremental may be more appropriate.

Does this mean that Continuous Architecture would not work in this situation? Absolutely not.  This is one of the key benefits of the “Toolbox” approach. Its contents can be easily adapted to work with Iterative or Incremental instead of Agile.

Continuous Architecture also operates in two dimensions: Time and Scale

The time dimension addresses how we enable architectural practices in a world of increasingly rapid delivery cycles, while the scale dimension looks at the level we are operating at (such as project, line of business, enterprise, etc…). We believe that the Continuous Architectural principles apply consistently at all scales, but the level of focus and the tools used might vary.

Please check our blog at https://pgppgp.wordpress.com/
and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

The Benefits of Continuous Architecture

Source: The Benefits of Continuous Architecture