A Trace in the Sand

by Ruth Malan

 

 

 

 

Architects Architecting Architecture  

February 2006entry

2/3/06 Introducing my Architecture Journal

I have decided to take my architecture notes online. This allows me to share, with whomever dares to follow, the journey's I take as I explore the core and the fringes of architecture territory. These journeys get documented more formally in the Resources for Software Architects web site, but for those who prefer to get the chronological ordering, with commentary, here goes... 

And to set expectations clearly: since these are my notes, I reserve the right to edit them, and to use them in my work.

2/3/06 Updates to Resources for Architects: Books and Links

Over the past few days,I updated various areas of the Resources for Software Architects web site, including links, EA links, books and the What is Software Architecture? page. We've also been asked to post several architect job opportunities, and I added a new area to the site devoted to links to architecture case studies that are publicly accessible.

... a site as big and comprehensive as the Resources for Software Architects web site is not built in a day. It takes constant evolution. Yes, some areas lag for a while, but it is because we are tilling the architecture field and we readily share the lessons we reap. The various books pages (classified by topics of interest to architects) were getting behind, I have to admit. They're better, but I need to put more time into re-synchronizing those pages with the books in our library.

Anyway, if you have published something you think we should be referencing, please let us know! We can't always respond immediately; we tend to have a LIFO email stack so feel free to try again—at times we are just positively swamped and untended email backs up...   

2/4/06 Updates to Resources for Architects: Dominant Designs

I added a piece on dominant designs to the Resources site, that collects together some useful references. Booch was musing about the distinction between architectural style and architectural patterns on his Blog. [4/7/08: In response, on 2/1/06 I emailed Grady saying, "When I am pressed to distinguish between architectural patterns and styles, I like to draw on the building architecture metaphor that architectural style was borrowed from. There, clearly, architectural style is a collection of patterns, from architectural to design to details such as trim (think of Victorian, contemporary, Cape Cod, Eichler, etc.). Architectural patterns (as in Christopher Alexander’s patterns and in the software field including the work of Buschman et al. and follow-on work) are more directed at a specific architectural challenge."]

I also added that I like to add the notion of dominant design into this mix (see, for example http://www.bredemeyer.com/ArchitectingProcess/ConceptualArchitecture.htm and http://www.bredemeyer.com/ArchitectingProcess/architecturalPatterns.htm).

We see the same patterns over and over again in architectures, and I have to conclude that, for example, layers, and in particular, the 3-tier variant, is a dominant design element. For most of us, it is our starting point. We automatically think of separating presentation from business logic, for example. We may further refine the business logic into layers, or add a common services "subsystem" (not strictly a layer in many architectures, as these may be accessed from any of the layers), and so forth.

We also see resource managers over and over in embedded systems these days. Yes, we can articulate and share resource manager designs as patterns (see Kirschler and Jain's book, Pattern-Oriented Software Architecture, Patterns for Resource Management, Wiley, 2004). Can we also say this is a dominant design element within certain types of systems, like control systems where resources are applied to handle performance requirements introducing the need for a resource manager? If we can, then we provide a point of leverage. For a while, it lets us focus our attention where we can provide differentiation, recognizing that in time a new dominant design will emerge. As architects we have to be on the watch for opportunities to reshape the order of competition with revolutionary new designs. But we can't spend all our time pushing the outer limits or we won't get our products and services out the door.

2/4/06 The Tipping Point

I've been reading The Tipping Point(Malcolm Gladwell, 2002). Being interested in every avenue for helping architects be more successful, my reading takes me some places I'd otherwise not go. Enough said.

Anyway, what brought me to The Tipping Point is wondering how we can be more effective at getting large communities to rally behind our architecture. As architects in this particular era, we face this challenge because we must simultaneously act as change-agents shifting the organizational culture toward one that is more architecture-friendly, and align the group behind our architecture. Yes, we emphasize the importance of vision in leadership. Yes, we provide guidance on making the vision more compelling (desired state interviews, vision stories presented in various visual and creative formats).

But I've been getting anxious that as a technical community that has matured in the age of email, we rely far too exclusively on email to get understanding and buy-in to our architecture approach. We complain of being meeting-ed out, and claim that email does the deed well; we like that it is asynchronous. But therein lies the danger. A number of people I know read email, but they don't respond. You don't know if they've read the email, and if they did, you don't know how they took it. Face-to-face, or at least voice-to-voice, you're more likely to get feedback, both verbal and non-verbal, that will give you get a better sense of whether they're getting your message—understanding it and being inspired by it. And you will get better input; input that will help you create a better architecture and more influential end-to-end story that connects concerns with architecture decisions.

So what do I take away from The Tipping Point?

Gladwell posits that word-of-mouth epidemics cause massive adoption of a product or service, and they are triggered by mavens, connectors and salespeople.

  • Mavens avidly seek and openly share knowledge

  • Connectors establish networks of relationships that can be the conduit for transmitting knowledge

  • Salesmen are persuasive, transmitting knowledge with energy and enthusiasm

Now, I think there are other effective ways to create intellectual contagion, that is, contagion of ideas. Talented writers inspire a following. How many people check in on Joel on Software on a regular basis? I know in the investment field, there are advisors like Casey in the energy and minerals area that inspire "epidemics" of smaller scale (because Casey controls the scale by limiting the number of people who can buy into his newsletter distribution). But even this "controlled" contagion among energy and mineral investors can noticeably impact stock prices.

Many architects are talented writers. They can effectively and persuasively convey using written word and supporting diagrams. If only everyone in the target audience would read these words. When it comes to writing, other architects are of the right-to-the-point-and-the-point-only variety, neglecting to share their reasoning and rationale; neglecting to persuade. And many—no, too many—architects have to be badgered most persistently before they'll write anything at all down!

Gladwell makes the point that different personality styles can tip an epidemic. I haven't yet made it to the end of the book, but so far I haven't seen him explore email and blogs as instruments in word-of-mouth epidemics. But I'd say, if you are trying to get your organization to catch fire and blaze a new architecture trail, the key is multiple communication channels and multiple personalities. Yes, email or a project blog (we need to get one going for HelpMatch) is one channel. But you just cannot get away from person-to-person transmission if you want to be infectious! And then it is a good idea to keep connectors, mavens and salespeople in mind. In our Role of the Architect workshops we have long shared Influence Maps, encouraging architects to track and tap into networks of influence within their organizations. Gladwell's work illuminates how to use that tool still more effectively, I think... perhaps...

Well, at a minimum, the Paul Revere story was worth the price of the book! I'll be using that one!

 

2/5/06 Speaking of Connectors, have you heard of Gerrit Muller?

I was thinking about how architecture has just taken off in The Netherlands. Why would this be the case? I'm not so conceited as to think the role we played tipped this epidemic, although outside the US we have done more workshops in The Netherlands than any other single country. We ran our first European open enrollment workshop there and that was some 6 years ago. I think of this as evidence of the attention to architecture, not the reason for it.

No, I believe it more likely that Gerrit Muller and Henk Obbink are the maven/connectors that tipped the architecture epidemic in their country. Gerrit might have been the classic introverted technical person. If he were not so passionate about architecture we might not know him, or of him. But his passion takes him outside himself. He nurtures a geographically-close community of architects, and he spreads his influence far and wide by freely sharing his architecture work, including workshop materials, on the Gaudi web site. Gerrit goes out of his way to connect. I mean, he really goes out of his way! For example, he has visited us in Bloomington, Indiana—twice!

Henk Obbink, too, is very active in the local community of architects and the global community of architects, doing community service work like editing the 2005 IEEE special issue on Software Architecture. Of course, Jaap Skekkerman has also been influential in the Enterprise Architecture space, and others like Jaap de Rijk and colleagues at Luminis have played a role. And those are just the influencers we see from across the ocean. I'm sure there are more. But we hear so many people talking about Gerrit and Henk, not just in The Netherlands, but elsewhere too, that we have to conclude that their role has been substantial.

2/5/06 Resources for Architects Reviewed on Amazon

Dana came across website reviews on Amazon, and checked to see if the Resources for Software Architects (www.bredemeyer.com) site had been reviewed. Low and behold, it had! This is Mike Tarrani's opening line:

"Can the adjective 'delightful' be used to describe a technical site devoted to software architecture? In the case of this site, yes."

And this is the closing line:

"Overall this site is a gem for software architects and those who want to understand this discipline."

It made my day! It is nice to be acknowledged.

2/6/06 GEAO: Architecture Connectors Reaching Out all the Way from New Zealand

GEAO, the Global Enterprise Architecture Organisation, has its heart in New Zealand. Though the board is truly global, the driving energy is still close to its birthplace. The idea was born on the daily train commute to/from Wellington, New Zealand. A handful of commuters sharing a common interest in architecture brought this organization to life because the founders saw a need for an international body to support and champion architects in the enterprise architecture field. Ben Ponne, the founder and director, is a classic maven/connector.

OK, I have to confess, each time I use these labels my discomfort index surges. But there is communicative power in a label with a documented, shared definition. We see this over and again in architecture and patterns. We articulate a recurring pattern or set of ideas and give it a name, and it becomes part of the lexicon, providing us with a shortcut to communicating a set of concepts with a single term or phrase.

This is what I do with books and papers. I enter into a discourse with them; challenge the ideas, integrate them as appropriate, and move on to the next source of generative ferment.

2/7/06 Booch's Software Architecture Handbook

My updates on the Resources for Software Architects web site took me back to Grady Booch's Software Architecture Handbook site a few days ago. Which took me to his Blog, which resulted in this Journal. But it also took me back to the section Booch wrote on Forces in Architecture. This piece is high on my recommend list! It is well-written, insightful; everything we have come to expect from Booch. But I have to confess, I am impatient to see the systems architecture pieces promised on his Handbook site.  In the Architectural Requirements section on the Resources for Architects web site I wrote:

"Still, since architectures are proprietary, we generally don't get to see too many (even as architecture consultants, we get to see fewer architectures in a lifetime than works of art in a day at a good art museum)."   

Booch is in a position to do much to change that for the architecture community. But he is also working on a patterns catalog as part of the Handbook. Now, I think a patterns catalog, with various ways of navigating into the space, is a needed contribution. I would hope that at some point I would be able to go to such a catalog, and find a proven solution to the architectural challenge I face. But cataloging patterns it is a painstaking project. With over 400 patterns in the catalog, the contribution is all the more apparent. And still I'm impatient for the system architecture portions of the handbook to be available. (Of course, we've been working on the Action Guide for Architects book for years too, so I understand life's juggling act.)

2/7/06 Updates to Resources for Architects: Architecture Gallery and Case Studies

In the meantime, I'm assembling links to architecture project artifacts and case studies in the public domain. I ask you to step up to the challenge and add to the list—first and foremost, work on HelpMatch; if you can, publish your architecture and send us the link; and point us to links to architecture project artifacts and case studies you have come across in the public domain. Oh, you should know that Booch has a "gallery" of architecture diagrams that he has collected from various sources. And try searching on "software architecture" in A9 (Amazon's search engine) and check out the 21,100 images that come up! Just kidding, but do check out some of them! It is rather a hunt-and-peck search because all kinds off stuff shows up. Or you can just check out what I have managed to integrate into the Case Studies and Artifacts page.

2/7/06 Updates to Resources for Architects: Strategy Maps and more

Putting the Visual Architecting Process Action Guides on the Resources for Software Architects web site is progressing; probably not as fast as you may like; certainly not as fast as I would like; but progressing. I went off to check if Strategy Map is a trademarked term. I didn't see any evidence that it is. But I found a really neat set of examples from UCSF (University of Southern California). It is so great that they are able to put their Strategy Maps in the public domain. Naturally I updated our Strategy page to include the link.

Which reminds me, our approach to strategy has evolved and this has not been reflected on the Resources site. I need to remedy that, but in the meantime you can take a look at:

  • Ruth Malan and Dana Bredemeyer wrote Cutter Consortium's June 2005 Enterprise Architecture Executive Report. It is titled "Enterprise Architecture as Strategic Differentiator." You can download a complimentary copy (a $150 value) from http://www.cutter.com/offers/strategic.html

This report covers our improved Strategy Framework  (the Identity/Value Propositions/Capability strategy model). We find that this strategy model is useful at any level, from business strategy to product strategy, and it is a great resource for architects who need to speak the language of business to understand and contribute to the business direction, and translate it into technical direction.

2/8/06 GEAO: New Site is Awesome

In another example of connector connecting, Ben Ponne gave me a sneak preview of the new GEAO site, and it is shaping up to be a really great site. Ben also shared the authors signed up to contribute articles to the 2nd issue of the GEAO Journal and the line-up is exciting. In addition to the GEAO Journal, there is also a GEAO Newsletter, providing two venues for authors to contribute to the field of Enterprise Architecture. The new site will go live at www.geao.org soon, but you can still access the old site there in the meantime.

2/8/06 Resources for Architects: nominated for architecture essential collection

I mentioned Tarrani's ego-salve (the review of our site on Amazon) earlier. We also have to thank Amit Midha of CMU for an acknowledgment on the SEI book revew page. Although strictly speaking not a book, we appreciate that Amit nominated our site for inclusion on the SEI architecture "essential collection" list. He gave this as his reason for nomination: "This is a knowledgeble site dedicated exclusively to software architecture." See http://www.sei.cmu.edu/architecture/essential_collection.html#nomination15.

2/9/06 Still Struggling with Tipping Point

There are parts of the book that I find tedious, and I think the main ideas could fit into an HBR-length article quite nicely. But there are ideas in The Tipping Point that resonate with me, and judging by the reaction (it is even integrated into a Wharton MBA course) it resonates even more strongly with a good many other people. 

What we are generally after is adoption—of our product; of our architecture. And many people, with varying degrees of "maven", "connector" and "salesman" qualities, will all play a role in moving the product, or architecture, along the adoption curve. We can, and should, get more self-conscious about adoption as a goal and adoption as a process that we can influence. So it behooves us to pay attention to who has the relationships and the personal style to act as conduits of influence—yes, sigh, who are the natural connectors. And it behooves us to pay attention to selling, to persuading, to influencing, and some of us are better at this than others—yes, sigh, some of us are natural salesmen. Now, in our world we have plenty of technology experts who track technology products and trends with enthusiasm, but we could do a whole lot better at understanding our customer's view of the marketplace. So it behooves us to become better at understanding our market (finding the mavens), better at establishing networks of influence (connectors) and better at persuading (salesmen)! These are qualities, not caricatures. My sense is that having them in good measure is good enough, because the adoption of our products, or architectures, don't have to be rampant epidemics to be good enough.

2/11/06 The Tipping Pointand HBR Article on Persuasion

I mentioned that I was reading The Tipping Point because I had this sense that many of us are relying too much on email and too little on face-to-face verbal communication. Gladwell is indeed strong on the importance of face-to-face communication because non-verbal cues are so influential. His discussion of persuasion centers on the non-verbal accompaniment to the charisma and argument of the talented persuader. I also read "Harnessing the Science of Persuasion" by Robert Cialdini (Harvard Business Review, October 2001).  Cialdini claims, in his opening paragraphs, to have figured out what executives need to know to become good at persuading. I found it notable that his examples seem to be applied more to first line managers...

At any rate, Cialdini (Harvard Business Review, October 2001) identifies six, what he calls, fundamental principles of persuasion:

  • Liking: People like those who are like them.
    Application: Uncover real similarities and offer genuine praise.

  • Reciprocity: People repay in kind.
    Application: Give what you want to receive.

  • Social Proof: People follow the lead of similar others.
    Application: Use peer power whenever it's available.

  • Consistency: People align with their clear commitments.
    Application: Make their commitments active, public and voluntary.

  • Authority: People defer to experts.
    Application: Expose your expertise; don't assume it's self-evident.

  • Scarcity: People want more of what they can have less of.
    Application: Highlight unique benefits and exclusive information.

These seem like recipes for increasing influence and worth paying attention to for that reason, but the studies alluded to in the paper were not studies of what makes great persuaders great. At least Gladwell tried to go after that. One big take-away from Gladwell is the positive outlook of the persuader. In our workshops, participants have remarked more than once that generally management is much more optimistic than the technical community. People who are pessimistic see all the good reasons why something cannot be done and are down-beat about it; they are just not going to be all that good at persuading folk to get on board and get it done! Architects, those that shine, are passionate about the architecture they are working on. Passion and pessimism make poor bed-fellows.

One take-away from Cialdini is his reference to the power of "loss language," framing in terms of what people stand to lose rather than what they stand to gain. He says "According to a 1994 study in the Journal of Organizational Behavior and Human Decision Processes, potential losses figure far more heavily in manager's decision making than potential gains." 

We tend to emphasize the positive. Our process seeks to understand business strategy, translating that into technical strategy, and creating the architecture that will enable our business to execute on its strategy. Our process thus naturally emphasizes the positive gains: we figure out what value propositions will differentiate us in the marketplace, we determine what capabilities we need to deliver this value, and we architect and deliver these capabilities. We identify risks and figure out how to manage risks, but this is not primary. Identifying differentiating value and focusing on delivering that value is primary.

We emphasize the importance of vision, the importance of a compelling desired future state, not just the "burning platform" we are trying to escape from. Again, we do encourage creating a view of the "loss picture" if that status quo (without the capabilities that the architecture will deliver) was to be projected out into the future. But the primary emphasis is on a compelling vision. Not magic, but rather real-world challenges and a path to high value.

2/14/06 Updates to Resources for Architects: Workshop Status and Action Guides

Well, the Enterprise Architecture Workshop is full and it is still just over a month away from the class! There are a several places left open in the Software Architecture Workshop and the Role of the Architect Workshop.

Yesterday I tried generating .pdf files of several Action Guides but Elements kept hanging, and I didn't want to reboot right then so I left off on that until this morning. Now I've added a few more Action Guides. Since this is a free service to the architect community, it obviously can't take precedence over revenue-earning work, but I try to add something to the tools (Action Guides and Templates) sections every day. 

2/14/06 Complexity: Intro

I have been working on complexity as another area I wanted to do more on as I rev the Role of the Architect workshop materials.  We ran that workshop several times in short succession during the latter part of 2005, so I didn't have time to substantially update the materials in the midst of that. But the open enrollment workshop in March comes at a good time for integrating several themes that I've been investigating because they have been coming up as challenges for the architects we work with. The architects are not necessarily noting these as challenges; but I'm looking for the root causes of challenges they are dealing with. One of the top principles for architects to follow is "simplify, simplify, simplify" (from Eberhardt Rechtin's classic text on Systems Architecture, 1991).

Architects: requirement analysts and developers press for turfWe need to differentiate; there is pressure to innovate. But innovation that amplifies complexity comes at a high price, raising the lifecycle cost for the business (development cost, maintenance cost, cost of unpredictability and market delays, support costs, etc.) as well as for users. In our view the architect (lead architect in particular, and the architecture team), is accountable for the design: for fit-to-purpose, fit within the environment, and so on. Often this is a potential turf-battle between marketing and R&D, or in IT, a turf-battle between architects and business analysts representing the business, and in many cases, to circumvent the turf-battle, lines have been drawn and responsibility does not reside with the architect. Organizations want to call the architect "the design authority," but they don't give the architect authority over the critical design decisions!

2/15/06 Resources for Architects: Case Studies

A few people have responded with links to architecture examples. Hopefully that will gain momentum as people find out about the case studies page, and inform their network of colleagues and friends in the architecture field (hint, hint).

I provide both a link on the case study name and the URL. I realize, naturally, that when one is online, the URL is superfluous, and indeed often very ugly. Sorry about that. But as soon as the page is printed, the links do not show up as URLs, of course. Yes, I know one could "Google" the title and find the referenced work even more easily than typing in an arcane URL. It is a matter of reference—the URL identifies exactly where the referenced work (at least at some point) was published online. I believe that the "old establishment" are going to have to recognize the legitimacy of papers published on the web, and create a standard for referencing them. If/when such a standard exists, please do inform me of it!

2/17/06 The Tipping Pointand Stickiness

Just in case you're wondering why I've had little to say about "stickiness," let me hasten to say we do deal a lot with the "content of the message." I've been pursuing the delivery of the message, hence the emphasis above. While there's a lot to point to in terms of message content and effectiveness, a good starting point is our GEAO Newsletter article titled "Guiding Principles for Enterprise Architects"—so titled because we were addressing enterprise architects, but the principles apply to software architects too.

We have promised Ben Ponne an article for the 2nd GEAO Journal, due shortly. Given that my energy is being focused by the upcoming Role workshop on architect effectiveness topics, I've concluded that I should leverage that and write another Role focused paper. That does leave us open to the kind of comment that came up on a Blog last year, where, upon asking about Bredemeyer training, someone responded that he thought we focused more on what the architect does than enterprise architecture. Actually, our focus in the Enterprise Architecture Workshop and the Software Architecture Workshop is on how to create a good, right and successful architecture (the architecting process) and in the Role of the Architect Workshop the focus is on how to be more effective (the architect skillset).

2/20/06 Resources for Architects: New EA Workshop Scheduled

Since the EA workshop we are holding in Las Vegas in March is already full with 4 architects on the wait list (and it is still a month away), we have added another EA workshop to the schedule in Q2. It is in Indianapolis, so Dana doesn't have to travel, making it feasible to fit it in.

I have noticed that in IT shops, the development focus is on training for enterprise architects. Even companies that have had enterprise architecture practices in place for a decade have been slow to institutionalize training/development opportunities for their software/application architects. Some are looking at training for entry-level architects, but the architects in the middle are left out.

In R&D, it is the other way round. Practicing architects are taking the software architecture workshop in big numbers, but the most senior architects in R&D are often not taking the workshop (in contrast to their IT peers on EA teams). One thing I take pleasure in with our workshops is that even senior architects get value. The more one knows, the harder it is to find good sources of new learning. So it is rewarding that, when senior architects do join their more junior architect colleagues in our workshops, all get more out of it. The senior architects add a lot of value, but they also get a lot out. They get reinforcement for messages and practices they have been encouraging in their organization, as well as new ideas and techniques.

2/20/06 Resources for Architects: nothing to report

A dull day. I don't think I read a single interesting thing! Well, there are still a few hours left. Maybe I can rescue the day from drudgery.

2/24/06 Resources for Architects: Architect as Design Authority

A dull day became a dull week, almost. Lots got done; but nothing interesting from the perspective of this outlet. But I rescued the week, starting work on what may become our offering to the GEAO Journal editors. Here's the first draft of the Introduction, still hot from the keyboard.

Introduction
When a bridge or a building fails, who do we hold accountable? If it is a problem with the design, then clearly we look to the architect. We expect the architect to have ascertained the requirements correctly, and to have designed a solution that addresses the requirements. We do not excuse the architect if failures occur because the requirements were not properly understood, or if the interaction among requirements was improperly accommodated.

Wind-induced vibrations caused the Tacoma Narrows suspension bridge to collapse; Clark Eldridge was responsible for the initial design, which was modified by Leon Monseiff to reduce costs. Eldridge accepts some of the blame for the bridge’s failure. [1]

Pedestrian motion caused vibrations on the London Millenium footbridge resulting in the bridge being closed 3 days after opening for several months, and retrofitted at a cost of £5 million (the total cost, then, being £23.2 million, or £7.2 million over budget). Arup (structural engineer), Foster and Partners (architects) and Sir Anthony Caro (sculptor) are accorded honor for the elegance of the design, and some degree of derision for its failure (Foster is known by the British tabloid newspapers as "Lord Wobbly", due to structural problems with the footbridge design). [2]

The Economist reports that the IRS wrote off $4 billion on the failed Tax Systems Modernization (TSM) initiative. Software Magazine reports this write-off as $8 billion. What is more, the IRS restarted the TSM initiative (in 2004?) with an expected cost of $10 billion, and an annual budget of $500 million. With some sleuthing, we find that Richard Spires replaced Fred Forman as head of the IRS Business Systems Modernization effort on September 17, 2004. Reading between the lines, we might come to the conclusion that at least Forman was not viewed as a success. There is no mention of the chief architect.

A £5 million bridge debacle and we know who is accountable. A $4 billion to $8 billion debacle in computing systems and we have to work to find out who managed the initiative, and find no mention of the architect(s) involved. More work and we could scratch this up, presumably. But the point is that the press is not naming names. It is true, too, that system architects are not being awarded honors or knighted (“Lord Wobbly” was knighted in 1990) for their successes.

This raises an interesting question: should we hold architects responsible for their architectures, so they succeed along with their architectures, and face a career threat when the tracks of failure lead clearly back to them.

When a product fails to measure up to expectations, who do we think is accountable? How about a humidifier that is impossible to fill without getting wet? The problem is localized to one component yet I doubt I am alone in looking to the architect to step to the plate and take the dousing.

How about a BMW 7 series that requires a special instruction booklet in the glove compartment so that valets will be able to park it ([3] Rust et al, 2006)? This is a usability issue, but again I would look to the architect as having overall responsibility for driving feature/usability tradeoffs.

When the business sets direction and IT fails to align with that direction, with debilitating impedance mismatch between the computing systems and the business processes they are supposed to enable, who do we hold accountable?

We would like to say the product, the system and the enterprise architects are accountable. But herein lies the rub: in the examples above, was there an architect? if so, was the architect (or team of architects) responsible for the design, or simply a consultant, giving advice? and was the architect chartered with understanding stakeholder requirements and negotiating the tradeoffs between cost, features and properties of the system? Cost, features and properties interact, yet they are often treated as a requirements consideration driven by business analysts or marketing and passed over the wall to the architecture team at requirements sign-off.

Understanding the problem to be solved is an act of interpretation, and this is best done by the person or team who understands the interaction between what is possible, at what cost, and what is needed and desired. Tradeoffs must be made on both sides: the user faces a utility envelope where there is a tradeoff between features and properties, and cost or timing; and on the development side, where there is a tradeoff between features and properties on one hand and complexity driving cost and development time on the other. These are not best dealt with as separate balancing acts, yet this is what many organizations are forcing, by separating requirements specification from architecture design, and creating separate islands of activity to create these two bodies of work.

When we stand back from the problem, we know that, for example, within certain parameters a capability may be reasonably cheap, but beyond those parameters the cost may be an order of magnitude more. We do not expect the system user or business analyst to be aware of these factors; we expect the architect to be aware of them. Yet we do not typically charter the architect with leading the product definition phase and integrating product definition (requirements specification) with architecture definition. In the building architecture field this separation would be considered ludicrous, I'm sure.

It is in vogue to say the architect is "the ultimate design authority," but what is generally meant is that the architect is the design guru who developers can go to for advice, not that the architect has authority over design decisions. We need to get to the point where the architect really does have authority over design decisions before we can hold the architect accountable.

Once we are clear about what the architect is responsible for, we are also clear when the architect is not responsible, in particular when he has been overridden by higher powers, or when his design is compromised by failure of a component to perform to spec. Remember, Eldridge only assumed “some of the responsibility” for the Tacoma Narrows disaster, but he was not responsible for drawing tight lines on cost nor the decision to go with Monseiff’s cost-reducing modifications to his design.

[1] http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge
[2] http://en.wikipedia.org/wiki/London_Millennium_Bridge and http://en.wikipedia.org/wiki/Norman_Foster

[3] Rust, Roland, Debora Thompson, and Rebecca Hamilton, "Defeating Feature Fatigue," Harvard Business Review, February 2006.

2/28/06 Architect Skills: Simplify, Simplify, Simplify

The architect's role in managing complexity cannot be over-exaggerated! In the first place, the architect has to be the fastidious watchdog weighing every feature for importance to differentiating value proposition on the one hand, versus additional complexity both to the development organization and to the end-user, on the other. The recent article by Rust, Roland, Debora Thompson, and Rebecca Hamilton titled "Defeating Feature Fatigue," (Harvard Business Review, February 2006), is highly recommended! 

We got taken to task for not highlighting risk management as a key responsibility of enterprise architects in a Cutter update. Actually, we do very often, in various forums, point to risk management as an important responsibility of architects. Yes, risk is important to manage, but we do tend to emphasize the different mechanisms architects use to manage risks. For example, I would tend to emphasize complexity management before risk management, but I would hasten to say complexity management is risk management--pre-eminently risk avoidance. I would emphasize the architect's role in strategy implementation before risk management, but I would hasten to say that the architect's role in translating business strategy into technical strategy and leading the implementation of that strategy is key to success, or alternatively put, key to avoiding the risk of failure--failure to align with the business and ultimately failure, or at least impedance, of the business. That said, we do explicitly consider risk throughout the architecting process. And we do keep asking the architects to look for what stakeholders value and for their concerns (the upsides and the downsides) so that we don't overlook something because we framed it up positively when another person sees it negatively, or vice versa.

 

 

I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog

 

February Topics

Architect Skills

Persuasion:
The Tipping Point
- Still Struggling
- Stickiness

Players in the Architecture Epidemic:
- Gerrit Muller
- Ben Ponne

Persuasion:
Cialdini article

Dealing with Complexity:

- Intro

- Simplify, simplify

Architect as Design Authority

 

Journal Archives

2014

- January
- February
- March
- April

- May
- June
- July
- August
- September
- October
- November

 

2013

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2012

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

 

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

 

2010

- January
- February
- March
- April
- May
- June
- July 
- August
- September
- October
- November
- December

2009

- January
- February
- March 
- April
- May
- June
- July
- August 
- September
- October
- November
- December

2008

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2007

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2006

- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

 

 

 

I also write at:

Papers:

- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010 

- Innovation and Agile Architecting: Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

- EA and Business Strategy: Enterprise Architecture as Strategic Differentiator, 2005

- The Role of the Architect:: What it Takes to be a Great Enterprise Architect, 2004

 

Ruth Malan has played a pioneering role in the software architecture field, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which emphasizes: architecting for agility, integrity and sustainability. Creating architectures that are good, right and successful, where good: technically sound; right: meets stakeholders goals and fits context and purpose; and successful: actually delivers strategic outcomes. Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like: the extraordinary moment principle; the minimalist architecture principle; and the connect the dots principle. Being agile. Creating options.

Feedback: I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I can be reached at

Use: If you wish to quote or paraphrase original work on this page, please properly acknowledge the source, with appropriate reference to this web page. Thank you.

Visualization

- Links to tools and other resources

 

Misc.

- Other Interests

 

Email:

-

 

 


 

Ruth by West

Copyright © 2006 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: February 3, 2006
Last Modified: January 25, 2015