Archive for Architect

Conway’s Law

The Wikipedia community describes Conway’s Law like this; I paraphrase it like this: if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. The organizational divides are going to drive the true seams in the system.

The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition drives team ownership. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational distance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete–structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.

One could say this is part of the innovator’s dilemma. Sustaining innovations, that is, incremental improvements within the cast of the architecture, are what the organization is adapted to be good at. But when a breakthrough innovation demands a new architecture, a new organization (unencumbered by power trees that grew up around the old architecture) tends to be more fleet in bringing the innovation to market.

Another implication of Conway’s Law is that if we have managers deciding on teams (what they’ll do, who will be on them, and how they will relate), and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture. They determine system chunks (services or components) and capabilities by deciding who will build what.

Conway’s Law also kicks in if we take an initial guess at the system decomposition (a first-cut conceptual architecture), allocate subsystems to teams, and sally forth–the team boundaries will tend to become boundaries within the system. Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks. Yet, architecture is where we address cross-cutting concerns, or at least those that needs-must be addressed with a system perspective so that when it comes time to compose the system it will have the properties stakeholders care about, rather than emergent properties that may or may not suffice.

Roles are defined by their responsibilities and associated decisions. Architect is a role. Any person may play one or more roles. That is, the architect role may be shared among a group of people (as in many agile project teams), or one person may hold more than one role (as in many small teams, especially in startups).  This may be overt and declared. And it may be the result of decisions that are actually effected. If management decisions determine the architecture of the system, they are in effect its architects. If developers determine the architectural decisions, they are in effect its architects.

“Duh!” you might well be saying. Yes, a lot of what is absolutely common sense when it is put plainly, is so obtuse in the face of perplexifying reality. Simply witness all the heated arguments and misunderstandings you get around the topic of the role of the architect.

But what does it mean? Architecture needs to happen across the interfaces, and this also means across the system/organization interfaces. It means that system architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other.

Other references:

Why do we need software architecture (how architecture serves organizational and technical purposes)

Who needs carrots anyway? (about the iron triangle and the interface between management and architects)


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). 


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)

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 is researching the software architect role for an upcoming article on, 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 (

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.