The Architect Is Accountable!

This post could be subtitled, "The Architect Makes Decisions... and is ultimately responsible"

We have previously identified this responsibility for decision-making as one of the most important roles of the Architect:

"The software Architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system."

In this capacity, the Software Architect has ultimate accountability for the results of the project. When things go south, people should turn to the Architect to recover... and explain. All too often, we see cases where an Architect goes along with a project until the "architecture is done" and then moves on. When the project gets into trouble, you hear "Those developers didn't follow instructions" or worse. It's the responsibility of the Architect to avoid even this potential, something that can simply be accomplished by remaining a fully engaged member of the team - operating as "we" and "our's" instead of "them" and "their's".

But the Architect's responsibility doesn't end there. The measure of success for the Architect is based on more than just the project results. He is also accountable for the Business and IT Strategy. It isn't enough to for the single project to successfully meet it's objectives, but the results must also contribute to these strategic considerations. Factors that are by definition more valuable and significant.

Being successful in this capacity will almost always require an ability to balance competing stakeholder needs. The Architect rarely finds himself facing simple black-and-white decisions, but rather the need to carefully select just the right shade of gray, and to do so under intense pressure and without enough time and not enough information. That's the life of the Architect. Philippe Kruchten summed it up like this: "The life of a Software Architect is a long and rapid succession of suboptimal design decisions taken partly in the dark."

But like most things in the endless balancing act of the Architect, we have to be careful not to fall into the deadly cycle of becoming the decision authority for every decision. While the Architect is accountable, he simply can't own every decision. Even if it made sense for some reason, it's simply not practical. The Architect is out-numbered by a factor of, perhaps, 10 or 20 to one on any given project, and those other 10 or 20 engineers aren't just drones - they're experienced professionals who's input is essential.

So where do you draw the line? There are many factors at play there, but we'll consider one important one. In "What is Architecture", we talked about the need to organize a team around the architecture. A key result of this practice is the establishment of a natural and effective demarcation of decision-making responsibility. In their article titled Guiding Principles for Enterprise Architects, Bredemeyer Consulting talk about the "Minimalist Architecture Principle" which essentially says “if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.”

This practice keeps the Architect focused on the most significant decisions - those of the greatest value (and consequence) and of the type that require the broadest perspective and authority. But we have to be careful. This is essentially a form of delegation. As is always the case with delegation, we can transfer the responsibility but not the accountability. The Architect remains accountable for the overall results, and he must put practices in place to effectively assess those results throughout every stage of the project.

A few of us were discussing this concept of accountability recently, and someone tossed out the idea that the Architect is responsible from "cradle to grave." That's a good way to look at it. The Architect is accountable from the first stages of ideation all the way through to the production release and beyond as this new capability helps to realize the overall Business and IT Strategy. We got to thinking, though, and decided maybe "grave" wasn't a good thought to associate with this accountability. How about if we just say the Architect is accountable "From Cradle to Glory."

Good Architecture Encourages Good Estimates

When it comes to project estimation, much has been written about the importance of historical contexts and correlations, and it only stands to reason that relevant historical data helps lead to more accurate estimates. As Steve McConnell points out in Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))¹, historical data helps to work around common sources of inaccuracies in estimation because it accounts for organizational influences, avoids subjectivity and unfounded optimism, and reduces estimation politics.

But do we get the biggest bang for the buck out of our historical data? While common approaches to estimation successfully leverage this data, there's still more we can do. Historical data is even more valuable when used in the context of effective architectural practices. In situations where it is possible to leverage consistent architectural patterns and frameworks, historical data can be captured and put to use at a lower level of granularity, resulting it much more reliable estimates earlier in the project.

Let's look at an example. In my experience, the most common practices have us maintain and leverage experience at the project level. In this approach, a database of project performance attributes is built up over time, supporting the establishment of prediction models for similar projects. For example, if an organization has completed 10 "green field", web-based, Java/J2EE projects for the Health Care industry using Oracle and MQ Series in a b2b services delivery model, and these projects have taken on average 47,600 man-hours to complete (.6 std dev), then it's reasonable to predict (for planning purposes) that a future project of similar parameters will also require 47,600 hours of effort. This is a common approach and certainly provides value, especially at the early stages of a project.

As a project progresses and the architecture is better understood and becomes more stable, the same principles can be applied a lower level of granularity. For sake of example (albeit perhaps contrived), let's imagine we get towards the end of Elaboration (assuming RUP for the moment), and we are satisfied that our architecture essentially consists of a collection of typical patterns like this:

A. Web Page (JSF)
B. Service Facade (stateless session beans)
C. Business Object (pojo)
D. Data Transfer (Value Objects)
E. Persistence (Data Access Objects)

Now let's imagine a straightforward business application with, say, 20 Use Cases such as "Create Account", "View Order History", "Make Payment", etc. If the team applies the architectural patterns consistently, it is completely reasonable to look at the project as a situation where the engineers will produce 1 (or n) of each of these above "components" for each use case. In other words, for each use case, a new Web Page will be created to talk to a new Service Facade using a new Value object for data transfer. The Service Facade component uses a new Business Object that handles the business logic. The new Business Object depends on a new Data Access Object (DAO) for data persistence.

If we have good historical data for what it typically takes to build a Service Facade or a Data Access Object (in this architecture), then the estimate nearly becomes a mathematical exercise... 20 Web Pages at 40 hours each plus 20 Service Facades at 15 hours each plus 20 Business Objects at 52 hours each plus... and so on.

While this is no estimation panacea, and it's only one part of the overall estimation process (for example, let's talk about the value of architecture on "impact analysis" another day), I've been able to apply this approach for a long time with very positive results. Of course, the key is designing and applying a consistent architecture and capturing the historicals at the relevant level of detail.


¹Software Estimation: Demystifying the Black Art. Redmond, Wa.: Microsoft Press, 2006

What's All the Fuss About Architecture?

Software Architecture is all the buzz in the IT world right now. What's up with that? I think of it like this. Over the past decade, the decentralization pendulum gradually swung full-tilt towards distribution. To a large degree, individual divisions or departments were chartered with building out independent systems, absent of any unifying IT strategy. In fact, in some cases, software was being put into production completely within a business unit with no IT involvement at all! New applications sprung up like dandelions, as businesses scrambled to respond to competitive pressures and leveraged the climate to wrestle "control" away from the IT "Borg."

While for some time, this approach yielded favorable results in terms of flexibility and speed to market, it was a course of divergence that could only lead to one place - the place we find ourselves today. Disparate systems, duplication of resources, closets full of unknown capabilities, inability to leverage corporate assets, etc, etc. Meanwhile, the "science" of Software Architecture and enterprise technologies have continued to mature to the point where intelligent IT strategies promote more enterprise-scale thinking and yield tremendous competitive advantages.

It'll be our job to ensure that the pendulum swings back into balance so we position IT to be the "go to" guys and gals for the business... a partnership of mutual objectives and ambitions... jointly pursuing the overall goals of the business.

Cheers.

What is Software Architecture?

While the science associated with Software Architecture is an emerging discipline in the software industry, there is little debate about the nature of its importance. The following quote from the Software Engineering Institute (SEI) makes the case loud and clear (http://www.sei.cmu.edu/architecture/index.html):

1. Software architecture forms the backbone for any successful software-intensive system.


2. An architecture is the primary carrier of a software system's quality attributes such as performance or reliability.


3. The right architecture - correctly designed to meet its quality attribute requirements, clearly documented, and conscientiously evaluated - is the linchpin for software project success.


4. The wrong one is a recipe for guaranteed disaster.

What is Software Architecture?

But what exactly is meant by "Architecture" in the software field? The concept has been around for a couple of decades at this point, and absent a formal definition, I think we can rally around the central themes embodied in the following "authoritative" sources:

IEEE

“Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” [IEEE 1471]

IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.

Grady Booch, Philip Krutchen, Kurt Bittner, and Rich Reitman

Software Architecture encompasses the set of significant decisions about the organization of a software system:

• Selection of the structural elements and their interfaces, by which a system is composed
• Behavior as specified in collaborations among those elements
• Composition of these structural and behavioral elements into larger subsystems
• Architectural style that guides this organization

G. Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process — AnIntroduction. 1999. Definition derived from Mary Shaw’s definition presented in 1995 at theFirst International Workshop on Architectures for Software Systems.

Len Bass (SEI)

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”

Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003.

Studying each of these definitions, we see several themes echoed repeatedely. The architecture of a software-intensive system consists of three cooperative elements: 1) The Structure - a static dimension illustrating the partitioning of responsibilities among subsystems, 2) The Behavior - a dynamic dimension representing the relationships and interactions among those structures, and 3) The Style - the principles and guidelines that motivated the structure - and should continue to do so.

What Does Architecture Consist Of?

Let's take a very high-level look at each of these elements and consider a very simple example. For additional insight, I'd encourage digging into one or more of the many excellent publications on the topic. I've listed a few of my favorites at the end of this post.

The Structure

The structural elements of the architecture capture the static set of subsystems/components that make up the system as well as the responsibilities of these subsytems and their organization into larger subsystems. An important consideration in this dimension is the dependencies between components and on other/external systems. The organization of the architecture at this level and from this perspective is also important from the standpoint of coordinating work effort and planning a project. It is frequently the case that a project team is organized around this structure - different teams responsible for delivery of different subsystems. This consistency between product architecture and "project team architecture" provides considerable value in planning and managing a development effort.
The diagram above captures at a grossly high level part of the static dimension of a theoretical e-commerce application that accepts credit cards. Capturing and articulating the architecture from this point of view helps to establish the context of the system and provide a frame of reference for decision making.

The Behavior

The behavioral dimension represents the ways in which the subsystems or components interact to fulfill the system requirements. A diagram such as the following represents the "messages" flowing between the components of the same hypothetical e-commerce system referenced above.

In this scenario, we can follow the system in operation as the Shopping Cart collects credit card data from the Consumer and uses the Customer Management System to get additional information from the consumers profile. With that data, a payment instruction is dispatched to the Card Gateway that leverages the Third Party Processor to execute the payment. After the payment transaction is complete, the Shopping Cart records the payment information in the Payment Management System.

The Style

Overall, the style dimension captures the principles and patterns that motivated the structure and behavior of the architecture. In some ways, the style is analogous to that of architectural style in building architecture (e.g., Roman, Gothic, Victorian, etc). This includes concepts such as architectural patterns, technical principles such as rpc and idempotency mechanisms, and values such as simplicity of design.

The style dimension effectively sets forth a vocabulary and a collection of guidelines and constraints - boundaries, if you will - that encourage effective decision making and clarify communication about the architecture. It's essential this dimension be explicity represented, as future evolution of the product depends on understanding the factors that influenced the existing architecture.

How is Architecture Communicated?

There are many ways to capture these key dimensions. The "4+1 Views" promoted by the Rational Unified Process and Phillipe Krutchen (http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf) is a common approach. More on that another day.

It's important to note that in whatever way the architecture is conceived and communicated, it is the responsibility of the architect (What is A Software Architect) or a team of architects to drive the towards conclusion, constantly navigating the murky waters, balancing the many competing stakeholder needs, and rallying the team around the "right" decisions. The future of the product depends on successful accomplishment of this mission.

In an influencial work a decade ago, Mary Shaw and David Garlan put it as follows, and I think many of us can attest to the truth of this statement:

"The software architecture you marry in haste will be there for you to repent at liesure."

Let's do what we can to get it right :-)

Suggested Reading

1. Kruchten, Phillipe B., The 4+1 View Model of Architecture, IEEE Software, vol. 12, no. 6, November 1995


2. Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003. (Software Architecture in Practice, Second Edition)


3. Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James;; Little, Reed; Nord, Robert; Stafford, Judith. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2002. (Documenting Software Architectures: Views and Beyond)


4. Fowler, Martin. Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley, 2002. (Patterns of Enterprise Application Architecture)


5. Shaw, Mary; Garlan, David. Software Architecture; Perspectives on an Emerging Discipline. New Jersey: Prentice-Hall, 1996. (Software Architecture: Perspectives on an Emerging Discipline)

What is a Software Architect?

Characteristics of the Software Architect

"The software architect must be well-rounded, posses maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of complete information." (Rational Unified Process)

Role of the Software Architect

• The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system.


• The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.

Skills of the Software Architect

• Experience in both the problem domain, through a thorough understanding of the requirements, and the software engineering domain. The software architect must provide the global vision for the project.


• Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.


• Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.


• Goal-orientation and Pro-activity with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done will be successful.

Many Hats of the Software Architect

• Visionary – Discovers innovative and novel approaches, translating highly-abstract concerns into tangible opportunities… and results


• Manager - Coordinates with all stakeholders to formulate and communicate a practical blueprint


• Salesman - Sells the ideas and appropriateness of the solution


• Developer – Helps develop POC or pilot to validate solution, patterns, practices, and principles


• Leader - Shepherd's from ambiguous and abstract to concrete and practical


• Coach – Mentors and coaches others on effective application of industry best practices


• Governor – Helps to establish architectural standards and guidelines

Responsibilities of the Software Architect

• Abstracts the complexity of a system into manageable models that describes the essence of a system by exposing important details and significant constraints.


• Creates and communicates tailored views of the software architecture to appropriate stakeholders at appropriate intervals.


• Provides leadership on critical decisions that designate a specific direction for a system in terms of implementation, operations, and maintenance. These decisions usually result in tradeoffs that define key characteristics of the solution, and they must be well documented and easily understood.


• Establishes quantifiable objectives that encapsulate quality attributes based upon which the fitness of the architecture is measured.


• Proactively leads the implementation during all iterations and monitors the adherence of the implementation to the chosen architecture.


• Collaborates with the Project Manager and other key disciplines to prioritize use cases and organize work to drive down risk and encourage strong project control structures.

Architect as Advocate of the Business

Architecture is “an instrument whose central function is to intervene in man’s favor”

James M Fitch, 1972

As an architect, one of our most important responsibilities is working with the business stakeholders to understand their objectives and help ensure an effective solution. What's more, we typically need to understand the problem domain (or learn it very quickly) so we can help define those requirements and develop the solution strategy.

The following quote from WWISA does a good job of capturing this responsibility:

"Architects spend the lion’s share of their time up front: listening to clients, understanding the totality of their needs and resources, scrutinizing feasibility, forming a practical vision of a structure, and creating a blueprint. As the structure is built, the architect intervenes in the client’s favor, ensuring compliance to the plan and guiding the vision through the tempest of design changes, crises and ambiguities. Client advocacy is the cornerstone of the architect’s role." (http://www.wwisa.org/wwisamain/role.htm)

The role of advocacy is exhibited in many activities (negotiation, scope management, corporate politics, risk management, prioritization, etc.), but let's quickly highlight just two that revolve around the principle of understanding the problem domain.

Product Definition

The architect's awareness and appreciation of the business domain is essential to the best definition of a software-systems capabilities. The architect is able to understand likely requirements and encourage penetrating assessment of key product areas. I like to think about this in terms of how understanding the "solution space" has influence over the understanding of the "problem space". It's true we want to maintain separation of our models and abstractions between these domains, but it's critical that the solution side have a deliberate and calculated influence on the problem side.

In my classes, I like to use the example of buying a new car. While this is a low-level example, I think it illustrates the topic well (and it's easy to personally relate to). With a few essential "market needs" in mind (e.g., 4 door because it'll be too hard to get the car seat in and out of the coupe when the new baby is born, 6 cylinder because this 4-banger isn't cutting it in Atlanta traffic, and candy-apple red because, well, just because), we head out into the "solution space" (wandering lots, reading brochures, taking test drives, talking to friends, reading Consumer Reports, etc) and begin to evaluate our options. The available options immediately begin to influence our understanding of the most suitable feature set - the best balance of needs and solutions - and we ultimately arrive at the best "product."

The architect is most effective at helping to arrive at this "perfect balance" when he or she has a practical understanding of the business domain - the "problem space".

Product Evolution

The architecture of a system is subject to the tides of change within the business environment being served, reinforcing that the architect should be familiar with the business domain. In this regard, the architect needs to anticipate future changes to the architecture, and integrate styles that lead to the most valuable types of flexibility, a challenge more readily met with an appreciation of the business domain. For example, architects of today's payments-related systems should be keenly aware of the industry trends towards payments convergence - the collapsing of disparate payments channels into fewer products with greater compatibility and higher-value capabilities. Likewise, regulatory changes in the financial services space are shifting the landscape and encouraging the overlap of banking, insurance, and health care services. Business factors such as these industry and government trends must be taken into account in the design of effective architectures.

Let's sum this up with a quote from Wikipedia. This is actually in reference to structural architects, but it seems fitting nonetheless:

"The practice of architecture is a business, in which technical knowledge, management skills, and an understanding of good business practice are as important as creative design." (http://en.wikipedia.org/wiki/Architect)

And I'll leave you with the following WWISA story reinforcing the close relationship between the business and the Architect. :-)

"The architect and client meet when it is all over and reminisce about the trials and triumphs. They hold a big party at a Mexican restaurant, complete with Mariachi Band, for all the builders, employees, and customers involved with the project. Those nay-sayers who whined incessantly and said it couldn't be done now stand mute, sipping their margaritas. (http://www.wwisa.org/wwisamain/role.htm)"

Anyone hear the music?

Ridiculous Simplicity (#1)

"Simplicity--the art of maximizing the amount of work not done--is essential." (http://agilemanifesto.org/principles.html)

When I was a kid and would start to make something into a big deal, I remember my mom accusing me of making a "mountain out of a mole hill." That may be an expression that only makes sense here in the southern part of the US, but it seems to be applicable to projects I see all over the world. The systems we undertake today, and the technologies we have at our disposal, certainly allow us to make mountains. Of course, we all know mountains tend to be rigid and inflexible - immovable. In response, a deliberate practice - a core value - of delivering simplicity has become even more important in today's IT climate. What I'm thinking about here spans both the problem space and the solution space... we must simplify the problems and simplify the solutions. But what does that mean?

Ridiculous Simplicity in the Problem Space

I bet we all can think of plenty of examples where we allowed the business problem to get out of hand. Allowed it to grow nearly unbounded. I've witnessed a couple of projects over my career where "we" fell into the "boil the ocean" trap in the problem space, imagining that a product could not go to market unless it had nearly every conceivable feature. We allow the project to get bogged down in "requirements gathering" and don't demonstrate the collective discipline (and confidence) necessary to establish direction and make hard decisions on trade-offs in the market. I'm thinking about things like which features are really required and which are not. It's true that there are market situations where a product should not be released without all the "bells and whistles" or "this and that", but those scenarios are rare. Generally speaking, we do our business partners a tremendous favor by encouraging an environment that releases "right-sized" product and builds on it over subsequent releases.

This reminds me of a story... About 14 years ago, when I first left the US Air Force, I was working with a team building an internal account payables system. Users of the system choose the appropriate cost center upon login, and about 10% of the users had rights to access more than one cost center. When the user was ready to operate on a different cost center, they would have to logout and then log back in, this time selecting the alternate cost center. I made a case that we should change the screen design to allow the user to choose a different cost center without logging out. This alternative design would simply place a drop down list or something to that effect in the product. The user would select the appropriate cost center from the list.

My boss at that time argued against this approach and helped reinforce the importance of managing scope on the project - and on the product. It's not just the 15 minutes that it would take to add the feature (and that's really all it would have taken), but it was also the longer term consideration such as "care and feeding" of this capability, the constraints it introduced on the future evolution of the architecture and design, etc. It was a 15 minute change request in this one project, but it had hours and hours of impact over the life of the product. My boss insisted, "one of my principle responsibilities is to control this scope." I learned a lot from this guy. I think we all can. Today, many of us can think of projects where we refused to let the "15 minute feature" get in, but also the dozens of other features, functions, etc, that ultimately lead to the death of a product or project - crushed under it's own weight. Where successfully managed, these products remain lean and responsive to change, able to keep up with evolving demands over a healthy and long life.

Ridiculous Simplicity in the Solution Space

We can see similar characteristics on the solution side. Most developers I know really care about the "right-ness" of the design and implementation of the product. Their heart is in it, and they want it to be "perfect." And high-quality, precise work is always right and proper. We should never settle for mediocrity. The trouble we seem to run into, however, is in the definition of "right" or of "mediocrity." How do we assess the "right" design and the "best" implementation? The tendency seems to slant towards more or bigger or complex, when we should evaluate a solution based on the degree to which it satisfies the requirement and on its simplicity - the elegance of its simplicity. Without direct energy applied, a team frequently migrates towards what I like to refer to as "someday maybe" design. The design begins to get tweaked in sometimes subtle ways to account for the idea that "someday maybe" we'll need to be able to do X, Y, or Z. The "right" design satisfies today's requirements without trying to predict the future, recognizing that the chances of predicting correctly have been shown to be very slim, AND, when the future comes and we know what it holds, we can change the design. At that point, we'll be in the advantageous position of knowing precisely what's needed (based on actual data and experience as opposed to predictions), and we'll be able to get the design "right". I'll assert then, that the best design is the one that satisfies today's requirements while leaving options open for tomorrow's.

Just one brief example while we're on the topic of simplicity in the solution space. I recently witnessed a project where there was a fairly straightforward b2b web service interface that precisely satisfied the market needs. Falling directly into the "someday maybe" trap, the team added additional attributes to this interface - attributes that were not used in any fashion today - just in case they may be valuable to the business in the future. Compounding the situation, the team built a separate database to store the service response and create reports to demonstrate whether or not the b2b partners were populating the unused fields. The cost to the business is significant as a result of design by prediction rather than data, architectural inflexibility, additional scenarios and code paths to test and design around in future releases, client implementations and documentation confusion, etc.

Wrapping It Up

On my teams, we incessantly strive to find the most straight-forward solutions to problems and execute those solutions with pinpoint accuracy. You’ll hear team members and managers echo the phrase “do the simplest thing that could possibly work” and challenging one another with "is that really the simplest thing?"

This is a key principle of an agile, nimble, and responsive development team. And interestingly, this principle manifests itself in the products produced by such team. The products themselves exhibit agile, nimble, and adaptable characteristics, essentially mirroring the nature of the team that created them.

I'll wrap up with this quote from Dr. Paul MacCready:

"Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%."

I've consistently found this to be overwhelmingly true. Without the precise data to back it up, I'll assert that a focus on simplicity reduces the overall work effort on a project by up to 50% and enables the Business/IT partnership to more quickly deliver higher quality software that satisfies the market needs. These same products then respond to the pressure of market change and evolution in a much more resilient manner, ultimately leading to higher profitability and better performance in the marketplace.

One last thing... I would expect these thoughts to stir questions on topics such as the following, each of which we'll take some time to explore in the near future:

1. Cost of Change curve
2. The necessity of automated testing
3. The YAGNI (you ain't gonna need it) principle
4. Refactoring