Elementary Lessons in Vision and Teaming

Have you read The Goal? It is (still) a pivotal book in the Lean movement. I’ve been telling architects that The Wheel on the School (a children’s story by Meindert deJong) is the hidden jewel of that genre—namely novelization of business fundamentals. I believe it could be a pivotal book in the networked, collaborative, dynamic teaming movement. Is there such a movement? In software development, we see it instantiated in Agile development and Visual Architecting.

I so like The Wheel on the School! The team was chartered: wonder about storks. The team went off, and in their individual styles, wondered. They created a shared vision. Then they each went off in different directions, like the spokes of a wheel, but with a common vision unifying their search for a solution. The whole village got pulled into the creation of the solution, at different points. The team told vivid vision stories to motivate and inspire various people along the way. More and more people got drawn into creating the solution; taking risks, doing what it takes. The core team, working like cogs, pulled in teams of teams. Sometimes all working together, sometimes as smaller teams. Fluid, dynamic, ever-changing teams. Through action, they made the vision real. People changed; changed their self-concept, changed the communities concept of them. In changing how they viewed themselves, in changing how they viewed others, they built the team. A team needs diversity and a team is transformative; or it can be. They made their vision real: they wondered, they created a shared vision, and they set the wheels of action in motion. 

This is Kotter’s 8 steps of leading change in one delightful story you can even share with your kids. Or have them teach you. An open mind. A willingness to wonder. A willingness to think outside the box of convention. If you want to create, to lead, and you don’t relate to this book, please do tell me! The first 3 chapters on creating a shared vision will either have your attention, or you’ll be lost in translation. Not so much to invest then. And, if you find it useful, by all means tell us what lessons you found radiating from this gem of book.

While I’m recommending books for leaders, I also really like  Stephen Denning’s The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative, Jossey-Bass, April 22, 2005.  I see he has a follow-up book due out in October called The Secret Language of Leadership, (2007). 


Architecture and the Agile Quest

If you’re interested in Agile and Architecture, here’s an interesting read, including the comments: The Demise of the Gantt Chart in Agile Software Projects, by Tate Stuntz on July 31, 2007. I have to agree with David Christiansen: “I’m not convinced there is such a thing as a methodology or process that can produce good architecture.People create great architecture, just like it is people that create great software systems. But are there things we can do to create better architectures, and better software systems? Of course I believe there are! That’s where process comes in.

In manufacturing we learned that if we inspect quality in at the end, the cost of quality (a term that refers to the cost of poor quality that leaks through the inspection process, as well as the cost of removing found defects) is much, much higher than if we find potential quality problems at the source, to ensure they aren’t inserted. 

Architecture defects, those that have diffuse impact across the system, are so expensive they are hard to recover from when they are only discovered once the architecture is hard-cast in code. Hard-cast, I say, because though we think software is pliable while we are writing code, the volume of it quickly amasses, and with it sunk cost and sunk time. And we don’t, as an industry, understand sunk cost and sunk time terribly well! It is a huge reset to go back and rework the system to accommodate an architectural change of any significance. Because we perceive software as highly mutable, we think we can recover if we scramble, but our accommodations to the code make it ever more immutable as the structure erodes to the point where it is hard and unpredictable to change.

More expensive still, have to be products that are defective in concept, set to miss the market. Getting the product or application concept right–the value propositions that will deliver customer advantage and delight–is not a feel-our-way-as-we-build kind of thing. It is a strategic matter. Or at least, get the strategy wrong, and all the tweaks in the world are going succeed only by amazing luck and sheer heroics.

And yet, it seems to be asking for suspension of disbelief to ask for time on a project where all that is being produced is models, diagrams, stories, even if this work is toward a minimalist set of strategic decisions. Putting features in front of users, why, that is what creating software is all about. That is where we can see progress.

Still, if progress is moving towards a better sense of what our customers value, across use contexts, and all that decision space complexity, then we can make a lot of progress quickly and cheaply with models (and mock-ups and proof-of-concept/prototypes). And by exploring how those features play out over our posited architecture structures, we can refactor early, cheaply, while all we are changing is models and descriptions.

To help people create great architectures, our process needs to:

  • lead us to work in an integrative, collaborative way (without becoming a “committee”)

  • explore and visualize value opportunities and value delivery mechanisms, to establish architecturally significant requirements and architecture strategy

  • learn quickly through iterative cycles.

Yes, this is an agile process, if we make models recognized citizens of the software world, with full rights to authenticity and budget! In all we do, we have to find a good balance. Our models should not be belabored, certainly not early on, by putting in too much detail or trying to make them look pretty too early in a tool where pretty is hard to do once, let alone with changes.

We also need to open up our “agile” concept of customer. I highly recommend  Hidden in Plain Sight. I’ve also written about delight (key to customer advantage) various places in my architects/architecting/architecture journal notes (e.g., Vitruvius and delightcircle of excellence and (skipping the first paragraph) Zappos demonstrates that IT Does Matter).

What we are trying to do is surface and understand value propositions that users and other stakeholders find compelling. And find and improve the structures (architectural components and mechanisms) that will support the system through the sprints leading up to the first release, and beyond.



Agile Architecting

The Agile Manifesto articulates the following core values:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

In essence, informal, iterative, adaptive processes that rely on the collaboration of empowered individuals are strongly favored over formal, bureacratic process and its accoutrements (plans, contracts, comprehensive documentation).  If we overlay these values with values for enabling dynamic teaming, value delivery and risk management, we have the value-set that underlies the Visual Architecting Process.

Short iterative cycles, early involvement of stakeholders, and visualization, allow for quick learning, early direction setting and iterative direction correction and refinement. But this learning is done with models as long as they are effective, reducing the cost of change as the architectural design is explored, refined and elaborated. Along the way, the architecture is documented, both to aid the architects in thinking through approaches and alternatives, and as a communication tool to get input and feedback from a broad set of stakeholders.

The process promotes early discovery of opportunity to innovate and differentiate, and builds alignment and motivation through a strong, shared vision and high-level system design that identifies system building blocks that, for large systems, become the units of agile development, allowing further innovation and experiment, with generally lower cost of changelowered by isolating the impact of change.

This process then, allows us to integrate the best of agile software practices along with other practices used to get complex products created in reduced timenamely, allowing more people to be effective, productive and creatively engaged in building the system, because they have clear commitments to and from the system via the system design, and, yes, its documentation.

Embrace agile development and refactoring. Just start with models, work with all of the agile philosophies while the team is using models and document with sketches (visual and verbal) of the overall system and the key architectural mechanisms. Some of our lessons are learned the hard way, through discovery that necessitates refactoring at the code level. Others can be discovered by modeling the system and refactoring at the conceptual architectural element (module, component, service) level. Others are more apparent; we have after-all, some experience building software systems!  Yes, the ground is constantly shifting under our feet–the competitive landscape, and the technological landscape, keep changing, sometimes in revolutionary ways. But at the same time, dominant designs emerge that see us through periods of system evolution.

Naturally, I’ve defended (just enough) architecture documentation various places:

This piece is intended to plead the case for documentation within an agile culture

Also related:

On Agile and Documentation

and while I wouldn’t toss the proverbial baby out with the bathwater:

Colm Smyth has a series of posts titled “Debugging Extreme Programming–Agile not Fragile” that is architect-friendly; see, for example, Refactoring, On-site Customer and Metaphor.




Comments (2)

That Vision Thing

I get challenged on the question of vision. Is it management’s responsibility to come up with the vision, or the architect’s? Well, this is my push-back: the architect needs to be sure there is one. Remember: no vision, no destination, a random walk.

If management has established a shared vision, and we have a shared understanding of this vision in terms of what it means for the technical community, great! Job done; get to work on architectural strategy.

Still, I can’t tell you how many projects I encounter where the technical people feel there is no vision. So, is there really no vision, or no vision the developers relate to? Either way, the architect has an important leadership role to play. And moreover, even if management “leads” on the vision thing, the vision will be the better for the architects involvement. The architect is (or should be) responsible for the goodness of the architecture (value delivered, structural integrity and resilience under change) as it is sustained through the incarnations it will take as market changes and internal forces impinge upon it. The project manager is responsible for each release, one release at a time. There is an important tension there.

The tricky part is establishing a shared vision without having it be an unmercifully drawn-out process unto itself. To do this, leaders ask that the job of articulating the vision be delegated to them by the community. This is a job of trust, and a balancing act between participation and traction. Then it is a job of informing and influencing, inspiring and persuading.

In engineering, we tend to use and appeal to logic as our principal tool for persuasion; logos, standing on the shoulders of ethos. We tend to eschew pathos, the appeal to the emotions; we neglect enthusiasm, the importance of building it in ourselves that it may light in others; we neglect to tell stories that connect personally, appealing to the common history and aspirations of those we would persuade.

On the subject of persuasion, there’s Gladwell’s triad for infections of epidemic scale: connector, maven, salesman (The Tipping Point). Or as I interpret the triad: relationship builders creating conduits for persuasion, knowledge that imbues the message with meaningful value, and the emotive power of the carrier. Overlapping with, but importantly extending the triad of rhetoric: logos, ethos and pathos.

Gladwell also makes the point that the message has to be sticky. This has two aspects: the message must be compelling but the environment also must be receptive. Good people act in more, or less, helpful ways depending on their perception of context. That is why we focus so much on context leading up to vision and strategy.

We need to build a shared sense of where to get to, and a sense of the context that behooves us getting there—our history, our present context, and the forces that will reshape our context. The really neat thing is that we don’t place ourselves in the forefront, trying to persuade and otherwise bludgeon everyone with the vision thing. Simply getting people in the room to talk about context, their view of it, and others view of it, builds a sense that this view, this context, is shared, and more than that, it has its comfort and its motivating force. And yes, by being careful about inviting key individuals with various important perspectives, we play a shaping role in creating a valid shared context view. 

If the vision that comes out of this sense of our shared (business or project) context and the forces that will reshape it, and the opportunities it opens up, is not the vision we hold, then we need to take a hard look at ourselves.

Being ethical as a leader, to me, means not setting out to be self-serving. Rather it means to honorably, responsibly, seek out the value that is compelling to our community, build a shared vision, build passion and commitment to attaining the vision, and lead the decisions and the action that realizes the vision. It is not about power or dominating the will of others (as in, telling them what the system must be, how it must be organized, how to make it “perfect”). It is about leading to value delivery by facilitating the best joint effort of the community, creating the spaces in which individuals can make their best contribution to a system that will be successful and, in the process, building their own self-esteem and satisfaction with what they are spending the better part of their daily lives on.


[This post draws from various October entries in my online Architecture Journal.]

Comments (8)

Architecture Documentation: Courage to Fly in the Face of Convention

I have learned what I know about good architecture from working with good architects, many of whom have set the bar for excellence in architecture documentation. That said, I am too often caused to lament that the only thing harder than getting engineers to read the architecture documentation is getting architects to write it!. So why bother? Who cares? It is only going to get out-of-date. It takes work, and isn’t that time better spent coming up with better solutions to the challenges we face? Or better still, writing code, which is the ultimate in system documentation–right???

An architectural decision that isn’t written down has a lifespan of, let’s see, what is the memory span of a goldfish? Actually, it turns out that a goldfish memory span is not just a few seconds as previously thought. And we’re even smarter than goldfish. Can’t we just rely on our individual and group memory? Well, we have all been in the situation where a decision we thought we made yesterday, is still under debate today, and we have to persuade and coax, inform and influence, brow-beat and defend all over again.

Writing the decision down doesn’t get us entirely away from this perpetual churn, but it does help. We get sign-off on the decision. Once that is achieved, we can demand that only counter-arguments that have a strong link to architectural requirements can be brought up in contention with the decision.

Still, the half-life of an architectural decision depends very much on the authority vested in the architects, and how this authority is formally and informally reinforced in the organization. And it depends on what the architects do to communicate the decision, and what support and follow-through they apply.

So, if we cowtail to the push-back against architecture documentation from extreme agilists, and our own disinclination to write down architecture decisions and thinking that went into them, then we are sending the message that the “architecture” is not a set of decisions but just a fluid initial starting point that we expect everyone to remold and reshape actively and without constraint–or restraint.

In some situations this may be just fine. If we are working on a novel system, without precedent in our experience and in the collective experience of our industry (so we can’t hire in the experience we need), then it would be foolhardy to create an architecture specification early on and expect to live by it through the life of the system.

Architecture is intended to constrain–and enable, but the price is that we must constrain; that’s what decisions do. Once made, they have eliminated some alternatives we might otherwise have picked. Yes, like stop lights, they enable and constrain. So, is it reasonable to constrain (and enable) ourselves early on in the project? While we are always pushing boundaries beyond what we already know, we are generally also working with a good deal of experience to leverage. To the extent that we can create an architecture that we can validate and build confidence that it will serve us through the first release, and prepare us well for subsequent releases, we should do due diligence when it comes to documenting our architecture.

But what is architecture documentation? In good part, the architecture documentation consists of the very models we use to think through and make the architecture decisions. In short, much of the work is already done, assuming that we use models to visualize and evaluate architectural approaches. The diligence part has to do with:

  1. making sure we write down the thinking behind the models

  2. keeping the models (and supporting explanations) up-to-date

Architecture documentation explains and justifies the decisions that embody the architecture. So we need to articulate the reasoning, tracing the decisions back to the requirements that drove them, keeping track of alternatives we weighed but ruled out and why (so we don’t have to make the same arguments again and again), and writing down assumptions we made (so if these assumptions are invalidated, we know we have to revisit the decision).

When we do this, we also help educate the engineering community, sharing the experiences that shaped our decisions. By documenting our reasoning like this, we make our knowledge explicit and shareable. Further, it makes us more careful, because we leave a record that can be assessed and debated.

One of the things we have to do as architects is figure out where to push back against the status quo, to lead out of the rut we are in to a better way of doing things; a better way that enhances our community’s quality of life. And we have to figure out which battles just aren’t worth it, because it takes energy and passion to lead these changes, and some changes are more important than others.

For the things that we see rising above this cut-line, we need to do what it takes to be effective. We must not allow ourselves to be lulled by the cries of “it’s all going to change anyway” to escape the effort it takes to write good documentation for architecturally-significant decisions. If we want these decisions to impact the behavior of people implementing them, we need to do our part in communicating them.

The architecture decisions must be recorded, so we have a ready reference that doesn’t depend on us being always in the room, ready to explain and defend each decision. The decisions must be communicated and understood. It is worth it, if the architecture decisions are worth it. So the decisions must be strategic and minimalist, and relevant. As soon as they are not, we must be on hand to adapt the architecture decision set.

Once written down, to be sure not everyone who should read the various architecture documents, will read them. But those that do will have a much better understanding of the architecture, and the rationale for the decisions it encompasses. Good models and well-written explanations get right into the head of the reader in a personal and effective way. The reader can engage, backtrack, hold an internal dialog with the material until it is well understood, or at least clear where the questions are. Each reader will be better positioned to explain to their  peers and reports what the architecture means, in the narrow direct sense and in the broader sense of its intent. This very effectively expands your capacity to champion and explain architecture decisions and catch misunderstandings and misapplication of the architecture.

All this presumes that you and your team can come up with an architecture. It does not presume that you make every architectural decision in advance of all coding. Not at all! But when you have a complex organizational setting (large number of developers, distributed teams, etc.), then you need to do more of the architecture work upfront, and document AS YOU GO, not afterwards! There never is an “afterwards” and even if there was, you’ll have forgotten much of the rationale, if not many of the important decisions. Besides, though we need architecture documentation to help us with system evolution, we need architecture to create a system that addresses our architecturally significant requirements in the first place.

Early on, figure out what the architecturally significant uncertainties and risks are, and figure out what you must do to resolve these risks. Leaving them until “you must deal with them” is risky business. Then work quickly, with a focus on architectural priorities, to get a minimalist set of architecture decisions explored, validated (through models, reviews and assessments, simulations, mock-ups, and early, focused development of critical pieces of the code) and documented!

The bottom line: No architecture documentation –> no architecture; no architecture and we rely on organic people-intensive communication processes that, on average, don’t scale too well. No architecture + big project –> project wipe-out.

Other Perspectives on Architecture Documentation

For Architecture Documentation:

On-the-fence about Architecture Documentation:

Creating Architecture Documentation:

See also Software Architecture Books and Architecture Documentation (links) in my Trace in the Sand Architecture Journal

[8/25/06: Had to republish this post so the sidebars would show up.]

[9/16/06: Arnon Rotem-Gal-Oz is blogging on the Software Architecture Document -- on 9/12/06. See also Deliverables sections of our Software Architecture Action Guide book chapters on Meta, Conceptual and (soon) Logical Architecture.]

Comments (1)

Opening Up The Innovation Engine

Corporate and product identity is important in helping customers narrow options and make choices in a flooded marketplace (Malan and Bredemeyer, June 2005).  Identity is a market simplifier. And it means that we have to think about markets and marketing differently. Take the iPod. It is all about identity. The iPod is cool, the iPod is at the innovation edge, the choice to go iPod is a no-brainer. Give your teenager or 20-something college kid another MP-3 player and you’ll whither in dismay at the ungratefulness of the progeny you raised.

Tom Asacker goes even further. He makes the point that in a world characterized by information flood, people make decisions based on gut feel. “You’re not in the real goods business any longer; you’re in the feel goods business.”

The important point is that in marketing and product development, we are going to have to pay attention to how consumers really make product choices, and factor that into our product and product family design, not just our marketing strategy. We can’t expect marketing to create brand miracles no matter what products we create, and we can’t expect our sales force to create customer relationships and sell our products even if they deliver a poor customer experience.

Customer experience is important in a world where direct referral (whether through blogs or personal relationships) is a major force in purchase decisions. Architects need to understand these factors; it is not just the role of marketing to sort out how to make products competitive. It is the role of the multi-functional team involved in product (and service) innovation.

We have to break down the walls that prevent us from thinking about customer experience, product and company identity, and features, holistically. Serializing requirements (marketing), architecture (architects), and detailed design and implementation (software developers) with over-the-wall hand-offs between phases and disciplines is (like wires) “so yesterday”—it is a mechanistic process for a simpler, slower, more rationalized age.

To compete today, we have to be differentiated in customers’ perception. And in today’s complex world filled with overwhelming choice, perception is shaped by subjective experience, stories, feelings—not a rationalized conjoint analysis of the feature set. We architects need to take this into account; great software, that is software that makes products and services great, is not just a technical matter any more. We have to integrate customer experience into our value-cost strategy and design decisions.

Here’s some blog posts on innovation and break-through thinking:


Modularity and what we can learn from Trek

I love my Trek bicycle, but with Shimano gears and brakes, and Bontrager frame, wheels, tires, and pedals, the ineffable Trek quality cannot be pinned down to any Trek-branded component. The success factor here: modularity with clear interfaces, and clear design requirements pushed down to the modules so that excellence at the level of the overall system is achieved through the composition of excellent pieces.

Bicycles have been around a long time, and there is a dominant design. That allows innovation to be focused on the components and subsystems, with less frequent revolution in the overall decomposition. Together these 3rd party pieces fitting into a standard decomposition nonetheless yield a system that is unique and differentiated. Modular components driven to excellence in of themselves, plus a clear sense of the differentiating system qualities, yields a distinctive product. Flawless. So well-designed I can say wthout reservation, I love this product.

It is the architect’s responsibility to create the architecture (with collaborative input from component designers): to make decisions about the system identity and integrity, and decisions about components and their scope and responsibilities, and address cross-cutting concerns and system properties. The architecture provides the context to push excellence, innovation and quality to the level of the components.

In the software world, in the pressure of the moment we allow ourselves to accommodate the architecture. Every compromise to the modularity of the system increases the future cost of change. But we live in the present. We have to get out of this singular mindset, and part of the way out is to have an architect with the clear and well-known charter to preserve the structure of the system—to defend modularity and ensure that the modular pieces do indeed work together to deliver the functions and properties required.

Feature set teams or storyline teams (or whatever else you call them in your group) tend to work across the layers in a system. This work partitioning helps drive out features that users can respond to and give feedback on, so they can be improved. Great! But it also makes it important to empower an architect to defend and preserve the architecture, and yes, evolve the architecture when, on balance, that is the best route.  

Objects, then components, now services, are all hyped because they promise to address the build-from-parts need in our software world, at ever greater levels of granularity. But solving our problem isn’t simply a matter of picking a programming paradigm that supports (larger-grained) parts. We have to become good at designing parts—parts that really fit our system; really fit our need.

I acknowledge that I am fundamentally, completely, biased here, but I can see no other course than through getting better at architecture, and better at protecting and preserving our architecture, and better at investing in evolving and regenerating our architecture. And better at investing in what it takes to completely revolutionize our architecture, even though that means we have to do so with a whole new set of people, which is counter-intuitive (see Rechtin’s book Why Eagles Can’t Swim, 2000).


What distinguishes the Software Architect?

Allan Hoffman at Monster.com is researching the software architect role for an upcoming article on Monster.com, and he asked me to give input. Here is his leading question (in italics) and my response:

What are the key elements differentiating the role of a software architect from related roles (project manager, programmer, and so forth)?

The role of software architect particularly comes into play for reasonably complex projects. These require the co-ordination of a fair number of people as they create, improve and extend a collective work product. This is not just a matter of scheduling and workload balancing. Software construction is very far from route manufacturing assembly. Rather it is a process of invention and inventive evolution.

Software architecture has to provide a context for this innovation, creating boundaries within which programmers can work with a high degree of freedom, while nevertheless delivering a system with a coherent identity, with parts that collaborate to produce services with service levels that not simply emergent, but rather the result of a reasoned, goal-oriented process.

Software architects are the people with the skills and experience needed to design these architectural elements that become units of work, and units of innovation and experiment, containing the cost of change through the initial experimental stages, and throughout the evolution of the system.

Software architects need to have real system development experience. But they are not just technically great. They also need to have skills that are more like those of managers, because they need to lead various communities (including developers, but also managers, and others), persuading, consulting, mentoring, and so on.

Software development is innovative work; getting people to work towards something with a coherent identity and integrity is a matter of getting people to voluntarily contribute their imagination and best effort to working towards a common vision, within a common setting of goals, principles and overall system structure, and with a good idea of the commitments their piece of the system must contribute to the overall system purpose.

Setting system goals is strategic, motivating and aligning people to achieve them is leadership, helping people understand them and be successful is consulting, navigating all the relationships and networks of influence to get things done in organizational settings is organizational politics. The architect must have all these skills, or partner very, very well with someone who does!

Useful References:

Added 7/24/06: Allan Hoffman’s article on the Software Architect Career is out and he has done a great job. You can see it at Career Spotlight: Software Architect (http://technology.monster.com/articles/softwarearchitect/).

Comments (1)

Architect: not just technically great

Complex software is a collective work product, so constructing software systems necessarily has a social dimension, complicated by the fact that the work is innovative and non-routine. And we can’t just dispense with teams: software teams are about two things: getting more expertise so we can build better products and applications, and getting more bandwidth. Yes, these are two things:

  • The first is about the complexity of today’s products requiring such depth of expertise in diverse areas that it becomes unlikely that just one person holds all that expertise. 

  • The second is about the number of person-hours required to construct the product or application. We can’t wait hundreds of years for software that takes hundreds of person-years to construct!

Architects who recognize that they are more effective when they enable their communities to be more effective, are well on the road to being great. It is not just about the architect making technically solid decisions. It is about enrolling others, and empowering them, to contribute their best. It is about inspiring and motivating, it is about generating goodwill, and it is about enabling co-ordination so that all the pieces will be the best they can be, and the system, composed of the pieces will be the best it can be. (And of course, by “best” I mean best fit to the need taking into account constraints and tradeoffs that have to be made.)

Yes, the great architect is technically great. If it were just about the people side, then we could have stopped at technical project managers and we would not have seen software architects emerge in all kinds of organizations and industries over the past decade or so. There is a strong technical dimension to the role. You can’t just slice-and-dice a system any old way and parcel the pieces out to teams and individuals to build and then recompose the pieces into systems that deliver the services with the intended characteristics or qualities! Even if you start with a common vision, but only have a rough cut at divvying up the system, then you either have endless unproductive bickering about what the pieces mean and who must do what, or you have people going off and making their best guesses at what they were meant to do and maybe, eventually, through immense hard work and mass self-sacrifice, get to something that works. But this path is littered with failures!

So, it takes experience and talent to create a great architecture—architecture that clearly identifies the structures and mechanisms that must be built to deliver the differentiating value propositions and foundational services of the system.  And it takes other skills to help the communities involved make their best contribution to the success of the system.

The architect who understands that he must get the great architecture that is in his head into the heads of the team, is the architect who begins to get the full scale of the challenge! And no matter how great we think the architecture in our heads is, it will be greater if we include others in the process of creating it. We will understand better what the architecture needs to be, to meet the needs of all who have a stake in it. This includes those who will create it, and those who have a perspective on the value this system could, and should, offer.


What is Software Architecture?

To set the context for subsequent posts, I thought we’d start with the topic of “what is software architecture?” Bass, Clements and Kazman’s definition of software architecture  (in essence, the high level structure of the system, described in terms of components and their externally visible properties and the relationships among them) has been very influential. While this definition has resonated with many people, the continuing discussion indicates some remaining uneasiness with definitions proposed so far.  We prefer to use the Bass et. al. definition and focus on the central concerns that software architecture addresses. (You might also like to take a look at Chapter 1: Software Architecture: central concerns and key decisions.) 

Complexity and Cost of Change

We need architecture to manage complexity and cost of change. Grady Booch puts it like this: “all architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” Cost of change goes up as scope of impact increases, so this definition covers decisions relating to system decomposition as well as those addressing cross-cutting concerns. Cost of change is also high if a significant chunk of the system has to be revised or rewritten, so this speaks to challenging pieces of the system.

Big Rocks First

We use the “big rocks” metaphor (see slide 6 and 7): If we start with the big rocks, then add the pebbles, and last the sand, we fit them all into our jar. And yes, we could even add water. The point is not that we can always ask developers to do more! The point is that if we start with the sand, add the pebbles, and then try to add the big rocks, we cannot fit them all in the jar. To fit them all in, we must start with the big rocks. Architecture is about getting the big rocks in place first.

But what are the “big rocks”? The architectural elements—the components and their relationships, yes. And architectural mechanisms addressing cross-cutting concerns or systemic properties, yes. Big rocks bear a high cost of change, yes. Is there more?

Architecture Implements Strategy

The architect of early generations of HP OpenView said “Architecture is the translation of business strategy into technical strategy.” This definition focuses on the strategic nature of architecture. What is significant, in this view, is driven by what is strategic, and what is strategic determines how we will compete. How we will differentiate dictates the big things we must get right, what hard problems we will tackle, where we will innovate, and where we must be ahead of competition. And it allows us to accept good-enough along those dimensions where we are not trying to create competitive advantage. Of course, even “good enough” may be challenging, especially when taken in conjunction with where we aim to differentiate.

The business or product strategy needs to establish what differentiating value we will deliver to our customers, our shareholders, our partners in the value network and our people. The architect needs to assess what capabilities will deliver this value. Architecture is about designing system capabilities that deliver the value propositions and reinforce the identity of the system (application, product, product-line, etc.) in alignment with the business strategy.

Architecturally significant decisions are those that must be made by the person or team who has influence and perspective across the system in order to deliver on the strategic objectives of the system.

Architecture Balances Differentiation, Complexity and Cost

The architect needs to balance the need to differentiate, with the lifecycle cost of the features and quality attributes we pursue. What we need to do, just to be in the game, constrains what we can accomplish in order to distinguish our products or services and business. For example, in many systems some level of security, scalability, and disaster recovery are threshold attributes not our avenues for differentiation. So we must develop mechanisms (authentication, encryption and firewalls; load balancing; failover, etc.) to address these challenges. Just delivering the base level of features and qualities is challenging, given the threshold set by intense competition in most markets.

Others will have a say in what our opportunities are to differentiate (e.g., marketing). And others will have a say in identifying the challenges we face to build and field systems in our domain (e.g., development). The architect needs to play a role in balancing what we would like to do, with what we are able to do given our resources and capabilities.

Architecture Expands Our Capability

Moreover, the architecture needs to play a role in increasing what we are able to do, and increasing the value of what we attempt to do, by allowing focus. Focusing attention, enabling specialization and separation, understanding where outsourcing or licensing can be leveraged, reducing complexity and scope where it is not essential to our value proposition. Knowing what to focus on and knowing what we can ignore—both are key to success.

Architecturally Significant Decisions

So architecture helps us manage complexity and cost of change, and deliver differentiating value in alignment with our business and product strategy. Architecturally significant decisions are those that the architect (or architecture team) needs to make in order to address these concerns (strategy, complexity, and cost of change). They generally include the high-level decomposition of the system and address cross-cutting concerns. What we do is driven by our business strategy, how we do it is driven by cost of change.

Furthering the State of our Understanding

Whatever else you might add, I hope that in the commentary on this post, you will share as concretely as you are comfortable with given the public forum (and your level of identity disclosure),

  • what are the major concerns you address through architecture, and
  • what kinds of decisions are architecturally significant for your system?

To set context for your observations, it would be very helpful if you would provide some background, such as

  • what kind of system you are working on (embedded system, e-commerce system, whatever),
  • some indication of complexity (like size of the development team), and
  • what your role is.

Comments (7)

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »