A Trace in the Sand

by Ruth Malan

April 2006

4/1/06 Architect Skills

To help position where architects need to pay attention, both on the job and in setting objectives for their personal development, I pulled off a number of current architect job postings from various places on the web. Many companies are positioning the architect role as one that is multifaceted hence relying on a plurality of skills and personal predilections; the architect is not just a technical "go to" person on the development team.

Yes, architects need to be both intelligent and experienced for they have to be very good at solving technical problems. Therein lies their credibility among developers. Without credibility in this constituency, there is no goodwill. Without goodwill, there is architecture-eroding behavior that ranges from covertly ignoring the architect's decisions all the way to overt escalation to get managers to sanction exceptions to the architecture.

And architects need to be good leaders, setting direction and using persuasion and influence rather than formal authority to achieve desired outcomes.

To reinforce this perspective and demonstrate that it is not just a self-serving claim (given that our business is consulting, training and mentoring for architects), here are quotes from some current architect job ads (I have added color to draw attention to the different areas of skill demanded):

Technological Prowess

"We’re looking for an experienced Architect/hands-on engineer who will be the key contributor to defining and developing our system level software architecture for these new designs. You will be responsible for designing and creating the proper architecture for each of our phones, ensuring that we are building a reusable set of software components that we can use to quickly scale the number of phones we can ship. You will have to span multiple layers of the technology stack from assisting with low-level kernel bring up on new mobile chipset designs, to helping define our wireless architecture across multiple cellular and wireless standards to assisting in optimizing our graphics subsystem for implementing new end user experiences on mobile handsets. You will also be responsible for performance tuning across our entire system, driving performance investigations and designing key subsystems across the software stack to drive the best possible performance for our phones. Key to this role is that you will be an active member of the development team, driving implementation where you can have the most impact and setting the pace for the rest of the development team in terms of writing shipping code. You must also find the idea of “influence without authority” second nature; you will need to lead by example and influence the development team to make sure that that everyone adheres to the proper design principles. You will understand the customer and partner requirements today, anticipating their needs for the future and drive the right technical solutions within the team and across other Microsoft device teams. You must also understand the competition and its impact on device technologies."

Company: Microsoft; Job Title: Software Architect; Job Category: Software Development; Product: Mobile Embedded Devices Product Group; Date Posted: 03/28/2006; Job Code: 158196

Leadership

"We are seeking a proven technical leader to drive the architecture of the Windows Live developer platform. This is a great opportunity for an entrepreneurial leader to drive architectural vision and strategy and to work with architects and technical leaders across the division to deliver a coherent and compelling platform. If you are passionate about helping developers build the next generation of web apps on top of Windows Live then this is likely a great fit for you."

Company: Microsoft; Job Title: Software Architect; Job Category: Software Development; Product: MSN Date Posted: 02/20/2006; Job Code: 154549

Plus Strategy Skills

"Position Responsibilities: The Management Architect will work with a small team of Cross-Divisional Architects in WEMD to set Architectural vision/strategy for current and future Management products and infrastructure. The Architect will work with Senior Technical leaders across the WEMD Product teams (MOM, SMS etc) and across Windows Server Infrastructure teams to define a tightly integrated Management Architecture for Longhorn and beyond. He/she will work in partnership with other Microsoft technologies to ensure solid technological integration with other Microsoft products, with a clear focus toward “delighting customers” in the Management space. In addition, the Architect will work with key Microsoft partners in the Management space to drive partnerships, innovation for maximum customer return on investment. The Architect will be responsible for driving both high and low level (detailed) design for the integration of Management products. Responsibilities will include planning, prioritizing key problems, doing cost/benefit analysis and strong customer research in order to best address most critical customer issues in the Enterprise Management space.

Requirements: This is a complex job requiring strong technical and strategic acumen. The successful candidate will bring the following experience and capabilities.
Hard Skills: · 15+ years engineering experience. Key industry player in the enterprise management sector. · Software product development/shipping experience with large and complex projects. Prior experience setting architectural direction, vision, roadmap for a key component in an enterprise level product or for the entire product. · Solid design/architectural skills and prior product development experience. · Strong architectural orientation but also able to think through market strategy to make technology successful and responsive to customer and partner needs.
Soft Skills: · Excellent leadership and negotiation skills (i.e., can lead/motivate people, manage multiple priorities and drive effective collaboration across groups). · Proven track record at establishing strong relationships and working effectively through others in order to accomplish business objectives. · Able to effectively communicate direction/vision, priorities on behalf of the team/division/Microsoft to senior level executives internal and external to Microsoft (Analysts, press, customers, partners, etc)."

Company: Microsoft; Job Title: Software Architect; Job Category: Software Development; Product Division: Windows and Enterprise Management; Date Posted: 12/15/2005; Job Code: 149438

Leadership, Politics, Strategy, and Technical Skills

"We are looking for a strong, experienced architect to be responsible for setting and driving the long-term vision for our shopping and marketplace products, focusing on building a market-leading consumer and merchant ecosystems. This position involves working through consumer interactions/scenarios, new business models and implications, product incubations, as well as driving cross-group efforts within MSN and with other Microsoft products. The successful candidate is expected to partner with other Architects including in Microsoft Research and senior leaders across Microsoft to maximize synergy between groups and to consult on the design of new features and work with the engineering teams to ensure the product is reliable, scalable and effective in meeting the product vision/roadmap.

The ideal candidate has successfully delivered products in the consumer/shopping space and has a proven track record of having invented and delivered market-changing technologies and/or having set new directions as a visionary leader in our industry. Candidate should be highly effective at influencing both internal and external audiences, and demonstrated the ability to inspire and motivate people around a strategy, as well as the ability to work effectively across organizational boundaries. The individual must be able to clearly set and articulate a consumer-oriented shopping vision, direction, and highly technical concepts to the development team and a wide variety of senior Microsoft audiences (Architects and Senior Management at all levels).

The individual must possess solid consumer, architecture and design skills; 5-10 years experience with Web technologies; and the ability to quickly come up to speed on new technologies. Passion for the user experience and demonstrated ability to drive and participate in prototyping efforts is required. Excellent communication and presentations skills required. A BS/MS in computer science or related field or equivalent experience is required. The candidate has to have strong architectural orientation but also be able to think through market strategy to make our products successful and responsive to customer and partner needs. He [really Microsoft!] should have a proven track record at establishing strong relationships and working effectively through others in order to accomplish business objectives."

Company: Microsoft; Job Title: Software Architect; Job Category: Software Development; Product: MSN Shopping; Date Posted: 11/02/2005; Job Code: 145532

As the Role Grows in Scope, the Architect Skillset Needs to Expand

In the architect job postings above, you may have noticed that the one with the most emphasis on technical responsibilities is the one most narrowly scoped. As the scope of influence increases to cover more organizational complexity and diversity of (vested) interests, more "soft" skills are required to gain and sustain organizational alignment and momentum to achieve collaborative goals.

Not Just Microsoft

Ok, Microsoft is not the only company hiring architects these days! And they are not the only one's recognizing the soft skills that the architect must have to be successful, especially as the architect's scope of responsibility is expanded. But they sure are positioning some exciting opportunities with a savvy sense of what it will take to go after those opportunities! Still, let us look at what other companies are looking for:

"Provide architecture products and services as the PLM PDM (Product Lifecycle Management - Product Data Management) Architect for Rotorcraft. Deliverables include definition of IT architecture directions, compliance to standards, applications, data and technical architecture designs. This position is responsible for developing optimum architecture solutions for PDM across all of Rotorcraft, and their integration with other tools. Collaborate with Subject Matter Experts, Engineering Customers and IT experts to define effective PDM architecture solutions that will help the current Rotorcraft environment integration and eventually migrate to the go-forward company PDM solutions (e.g., CAD/PDM - ENOVIA LCA, Enterprise PDM - TCEnterprise). Support PLM processes and overall company strategy to leverage common tools and processes, and other go-forward directions such as V5 tools suite. The candidate will coordinate with other Boeing enterprise process and tool focals and be an active member of enterprise process and tool development teams. The Architect will be expected to effectively lead, communicate and represent the architecture solutions to all Rotorcraft teams as well as other organizations across the enterprise as needed. Additional responsibilities such as application support and services and product architecture consulting to a wide array of audiences will be required."

Company: Boeing; Job Title: Rotorcraft PDM Architect; Job Category: Information Technology; Product: Rotorcraft PDM; Date Posted: 3/10/2006; Job Code: 06-1005462

Leadership, Politics, Strategy, Technical  plus Management and Technical Consulting Skills

"Senior Communications Payload Architect will lead internal research and development as well as new business support for a government spacecraft communications payload. Competencies:
Technical Skills & Knowledge: Experienced designing a large variety of spacecraft communication payloads. Specific domain knowledge in microwave spacecraft communication payloads required. Expertise in requirements, performance, hardware development required. Experience should include bent pipe communications systems, DSPs, reflector and phased array antennas, low noise amplifiers, frequency converters, frequency reference systems, traveling wave tubes and high power microwave filters and transmission lines. Ability to trade RF performance with spacecraft thermal, mechanical, space physics issues, cost, schedule and risk expected.
People Working Together: Effectively participates in accomplishing team goals; encourages learning from one another; creates group cohesion; gives and seeks specific, constructive feedback; works effectively with other work groups; values the contribution of people from diverse backgrounds; involves others in decisions that affect them.
Problem Solving/Judgment: Gathers, examines, and interprets information from different sources to generate effective solutions to problems and make sound business decisions; generates alternate approaches to solving problems when needed; demonstrates awareness of the likely consequences or implications of judgments. Generates and implements new and useful ideas; ideas reflect 'thinking outside the box'; explores alternatives; takes risks and tries new approaches.
Dependability: The ability and willingness to take ownership of work activities and ensure they are completed accurately, efficiently, and in a timely manner. This also includes being reliable, trusted, and accountable for completing work activities.
Leadership: Demonstrated ability to lead a multi-disciplined team. Leads tasks and people effectively; guides and coaches others to improve skills and achieve challenging goals; inspires and motivates others; solicits and considers others' opinions. Takes independent action; seeks out additional assignments or tasks; make recommendations to improve systems or procedures; demonstrates a strong work ethic and sense of urgency for completing work assignments; meets commitments; seeks out and accomplishes professional development opportunities.
Typically person in this position would possess 20 years experience."

Company: Boeing; Job Title: Communications Payload Architect 6; Job Category: Prod Engrg & Technology; Business: Integrated Defense Systems (IDS); Date Posted: 3/15/2006; Job Code: 06-1005999

"This position will focus on several e-commerce systems and call center systems in the Staples Delivery business unit. Individuals with extensive Architect/Leadership experience in e-commerce initiatives for enterprise systems in a J2EE environment will be considered. Consulting experience is a strong plus. The Sr. Application Architect will:

• Provide consultation and leadership to multiple project teams
• Ensure projects are aligned with the IS Strategy and compliant with technical standards.
• Identify opportunities based on technical knowledge and industry trends.
• Serve as the technical application design authority on multiple projects
• Create macro design (high-level design).
• Facilitate initial meeting with development lead to agree on process for design.
• Establish regular meetings to review technical designs and provide mentoring and guidance.
• Mentor development teams on object-oriented analysis and design of distributed, web-based architectures.
• Mentor on all aspects of Java-based design (J2EE Architecture, application design, tooling, best practices, standards, etc.)
• Maintain a knowledge base of emerging technologies and products.
• Work with our software vendors to understand and leverage existing product capabilities and shape direction of the product to best benefit Staples.
• Meet new vendors to increase awareness of technology trends and assess the potential benefits to Staples.
• Create technical standards and best practices, leveraging industry standards.
• Communicate and evangelize the use of standards and how the vision of a services-oriented architecture can be realized.
• Create processes and techniques that will improve performance and maintainability of applications.
• Perform technical assessments for a range of circumstances: application hosting, business acquisition, software vendor, etc.
• Develop a deep understanding of Staples’ business strategies.
• Advise senior IS leadership (technical skills required, organizational structure).
• Build and sustain commitment to IS strategy by mentoring lead developers and advising IS management.
• Shape technical strategies by working with enterprise architecture group (Technology, Strategy and Architecture Group).
• In collaboration with enterprise architecture group, develop future state vision of a services-oriented architecture (SOA). Create and maintain evolutionary plans to move future state vision of SOA."

Company: Staples; Job Title: Senior IS Architect; Date Posted: 11/02/2005; Job Code: #12717BR

Reflections

Well, it was easy to make today's journal entry positively verbose! I hope Microsoft, Boeing and Staples don't take offense at my liberal cut-and-paste quotations from their job postings. And I hope that your boss doesn't take offense at my exposing you to these job opportunities!

But I think the point is colorfully obvious: if you want to grow in influence and responsibility as an architect, you need to develop yourself in directions you might otherwise have associated with the management career track. For many of us who think of the architect career track as a growth path for technical people, this comes as a distasteful surprise. But it is all about achieving success through others. Architecture is about expanding the capacity of the organization to innovate and address more complex challenges.

Yes, as architects we need to be the watchdogs of complexity, aggressively resisting the temptation to add features or over-stretch towards ultra-you-name-it qualities. But we also have to recognize that our world is inexorably moving towards greater technological underpinnings yielding capabilities previous generations never dreamed possible. So complexity is here to stay. We can only work to manage in the face of complexity, and to reduce our exposure to complexity by being disciplined about scope and working to simplify both the nature of the problem and the organizational tasks in tackling it.

Through architecture we harness the talents of others to build capabilities we could not otherwise build effectively. Eb Rechtin observed in his seminal book (1991) on system architecture that architects have technical skills and skills that overlap with those of managers. Designing and building capabilities requires technical and domain knowledge together with systems design/system thinking prowess. Harnessing the talents of others is what drives the need for management-associated skills like leadership and facilitation.

April Fool's Day Joke?

Now you may be thinking, with a sinking heart, that this is an April Fool's Day post that really got you going; or you may be thinking with a sinking heart that this is NOT an April Fool's day joke and you wish it was! If you are in the architect role, it has confirmed your suspicions: it's not just you, it's not just your organization; it's all about politics and no-one told you this when you got into computer science some 10 to 20, maybe even 30, years ago! Even your technical decisions have to be made with politics in mind: Eb Rechtin (1991) said "if the politics don't fly, the system never will." He was chief architect and director of NASA's Deep Space Network and president and CEO of The Aerospace Corporation from 1977-1987, but the lesson applies to the rest of us too.

Still, there is also a delicious challenge in going after and accomplishing big things. We can do more, make a bigger impact, if we can help talented people work effectively together on something of compelling value. There are the day-to-day frustrations, but if we have a vision we can make it all worthwhile to ourselves and to those we lead.

[8/14/08: Eb Rechtin died on April 14, 2006.]

4/1/06Architect Skills: Some Strategy Pointers

Here's a useful quote to take to your business leadership: It is from the article by David Barnes, CIO of UPS, titled "How Business Should Drive Technology: Why UPS is always asking if what it has is the best and whether it can do better," Optimize April 2006, Issue 54:

"When IT is viewed as an equal partner at the strategy table, companies will be more successful in innovating and sustaining growth and competitive advantage."

On the topic of IT's role in a companies innovation engine, Laurie Orlov, VP of Forrester Research, said

"You need to assign business-savvy and technology-aware IT people to go into the business, whether through shadowing or interviewing, and identify uses for technology that may already exist in your assets."

and

"When you hear CIOs talk about IT alignment and you ask what they do, specifically, they say that they do a status report periodically. They have to do more than that—they have to market the IT department. ... You need to market your strengths as the repository of technology smarts in the company."

This quote is from "Is Someone Else In Your Company Better At IT Innovation Than You? The CIO whose department gets left behind in driving innovation has some catch-up work to do," Optimize February 2006, Issue 52

4/5/06 Updates to Resources for Architects: More on Architect Role and Skills

I'm pulling together several threads from this journal and elsewhere on the web to add an expanded area on the Role of the Architect on the Resources for Architects website.  This will be a work-in-progress for a while, and now I seriously have to work on HelpMatch to get some deliverables ready for the Indy Architects Community.

4/5/06 Architects: Building versus Software

I came across this interesting post: Building Construction is like Software, by Matisse Enzer on April 3, 2006. Usually we see the analogy being used in the other direction.

There are those who object most vehemently to the use of "architecture" and "architect" in the software domain (see for example the "Hiring the phantom Java architect" discussion on TheServerSide). We even get email to this effect from time to time. Like we're responsible for this appellation. Still, I happen to think it is a good one.

Analogy is powerful. And analogy is dangerous; those whose predilection is to take things literally, have a hard time with analogy and metaphor. We should bear this in mind. Metaphor is a powerful tool to use in creating architectural integrity (see, for example, our discussion of strategy/meta-architecture), but there are some who will see all the ways in which your metaphor is not applicable and it will distract them from the alignment and synergy you are trying to create. Not that we should allow the few to ferment anger to the point it is fearsome; that prevents us from getting big things done through others.

4/7/06 Blogging as Catharsis

What I love about blogs is that some really insightful thought is poured forth, though we have to mentally sidestep the "cow pies." Provocative essays posted to stimulate discussion, bring out strong arguments for and against the essayists point of view. What do chocolates, music and retaliatory blogging have in common? They activate nucleus accumbens! Or something like that. According to Gardiner Morse ("Decisions and Desire," Harvard Business Review, January 2006) our brain's "reward circuits" are activated in response to the anticipation of money, of food, of sex... and of getting revenge and delivering punishment to those we see as ill-behaved.

4/7/06 Blogging as (Historical) Commentary and Insight: Tracking the State of Software Development

First, here is a snippet from a discussion on the relationship between organization structure and code structure stimulated by Nicholas Carr. Carr, reporting on a study by MacCormack, Rusnak and Baldwin, commented:

"As a proprietary commercial product, Netscape Navigator was designed to optimize its performance. Modularity was neither a goal nor a necessity. Having a lot of interdependencies in the code was, it seems likely, the easiest way for the close-knit team to enhance the performance of their product."

I'm going to quote Bill Higgins response because it makes an important point about market pressures and code state, as well as experience and good architecture:

4/7/06 ArchiTECt: More on Architect Role and Skills

During the Role of the Architect workshop at the end of March, one of the architects emphasized the TEC in the word architect. Great! That is the necessary foundation, and the ongoing touchstone, for our success as architects in the computing/systems/solutions space. We have to be able to make technical decisions that are respected in the developer community. If we are too removed from our technical roots, we will have a hard time facilitating, guiding and making decisions that stand up under developer scrutiny. We need to build trust and goodwill, so that our stakeholders are willing to advance the goodness of the architecture rather than casting stones at it to see how much they can break.

4/13/06 ARCHitect: More on Architect Role and Skills

But the architect is the person (or team) with the whole-system purview, hence the emphasis on ARCH in architect (in the section title). The architect deals with over-arching concerns. What are the really big things we have to get right, or we fail? What are the concerns that cut across the pieces of the system?

4/14/06 Software Architecture Versus Design

For those who still wonder why we need the concept of architecture when we already have the concept of design: In the early to mid-90's we were drawn into the nascent architecture field because the design approaches of the day (Booch, OMT, Fusion, ..., leading up to UML and RUP), though promising, still left us holding the ball of complexity. To address complexity, and specifically the problems of tractability, manageability (in human terms), and large-scale (re-)use, we needed to work at a higher level of decomposition than classes, and a higher level of architectural element (components and mechanisms) design to achieve system properties in an intentional way.

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 ditched and rewritten, so this speaks to challenging pieces of the system.

Indeed, for years we have been using 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 the developer to do more! The point is that if we start with the grains of 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?

The architect of early generations of HP's Openview said "Architecture is the translation of business strategy into technical strategy." This definition focuses on the strategic nature of architecture. Architecture is about designing system capabilities that deliver the value propositions and reinforce the identity of the system (product, service, product-line, etc.) being architected. What is significant, in this view, is driven by what is strategic, and what is strategic determines how we will compete. What is the value we will deliver to our customers, our shareholders, our partners in the value network and our people? What capabilities will deliver this value? What services and properties must characterize these capabilities in order to deliver this differentiating value? 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.

What is architecturally significant, then, is the decision of technically-experienced, strategically-minded architects of a given system (or set of systems, depending on the scope of the architecture). What is architecturally significant differs from system to system, depending on the strategy; depending on what value this system will deliver and how it will support the differentiated identity of the business and its products or services.

Although these decisions about architectural significance and relative priorities are the responsibility of the architects, they, like the architecture design decisions, are not best made by the architects in isolation. They are best made by the architects in collaboration with the stakeholders they need to partner with for the system to succeed in delivering differentiating value. These stakeholders include customers and business leaders responsible for the business longevity and competitiveness in capital markets, and they include those in the development community (project managers, developers, test/quality engineers, etc.).

ARCHitect, Again

The architect then, makes decisions that require system-wide scope of visibility and responsibility. And the architect also spans the chasm that has existed between "the business" and IT or R&D.

4/18/06 Architecture and Requirements

In many organizations, we have created a divide between "requirements" and "design" insisting that "design" focuses on the "solution" and "requirements" focuses on the "problem." But we have to recognize that this separation is an artifice.

What we capture as requirements is going to constrain what we can offer in terms of user experience and life cycle costs for the system. The user experience is determined by architectural concerns like system capabilities (services or features, with associated properties or service levels) as well as usability concerns.

Use cases (or whatever vehicle is used for requirements) capture the (intended) capabilities of the system in terms of use case goals and the interaction between the actors (users and other systems) and the system. But whose intent is being captured here? Is it the intent of the user or the intent of the person capturing the requirements? That person is interpreting, focusing, shaping the conversation about user requirements. 

Requirements "capture" needs to be a active, creative collaboration between the designer of the user experience and those who can shed light on what is needed (including future users, and users of the current version of the system).

Consider these anecdotes:

When Dean Kamen (yes, the inventor of medical devices and also the Segway) asked "where you would put a third eye if you could have one?" everyone said on the back of their head; without hesitation, generally, on the back of the head. But when Dean said, "what about on the tip of your finger?" everyone agreed, without hesitation, that that was much better!

Henry Ford reportedly said “If I had asked people what they wanted, they would have said faster horses."

TWA asked Douglas Aircraft Corporation to produce an aircraft with three engines. When Douglas engineers probed for the reason for this "requirement," they found that the desire was to be able to fly safely even if one engine was disabled (this was in the 1930's when engines were not so reliable). Douglas produced the DC-1 with 2 engines, and proved that it could safely fly with just one engine, taking off from Albuquerque, NM and flying safely to Winslow, AZ. Only one DC-1 was built, but it was the forerunner to the DC-3, which helped make air travel popular and economically viable.

If the architect is to be held accountable for the system being good, right and successful, then the architect cannot be walled off from the critical aspects of the design work that has to do with creatively interpreting and innovating to achieve a compelling user experience and making decisions that will have huge consequences for the life cycle cost of the system!

Which is not to say that the architect (or architecture team) needs to do all the requirements work. But it does mean that the architect needs to be involved. The architect needs to have direct contact with stakeholders. She needs access to the business management to understand the strategic direction and lifecycle cost goals for the system. And she needs access to users, to understand the context into which the system will fit, as well as the user goals that the system will support. Further, the (lead) architect needs to own the architecturally significant requirements, and the decisions about what is architecturally significant.

4/19/06 Architects and Requirements continued

For many, the necessity of the role of the architect in requirements is self-evident. The architect job descriptions quoted in the April 1 entry above, make it clear that at least some organizations are positioning the architect's role as encompassing requirements and technical strategy setting. 

But there are also many organizations that have worked hard to create and fill the business analyst function, and many architects we work with perceive that getting access to business users (and strategic management, for that matter) would be as unlikely as walking on water. The business analysts become gatekeepers of the client relationship, and immediate managers become gatekeepers guarding access to higher levels of management. And no matter how the architect job is positioned in the job ad, or by me as an advocate for what architects need to do, be and have responsibility for, the architects just have to work with what they get served over the wall at them.

This is a disabling proposition for many architects. But there are those for whom it is just part of the challenge. Architects, in this formative era, are part culture changers. In their organizations they have to influence and lead change. The best way to do this is not by being churlish and negative; on the contrary, the way to do this is by being positive and energetic, setting an example of goodwill and partnering effectively with those with overlapping responsibilities. 

4/19/06 Architects and Partnering

An area of skill development that we emphasize for architects is that of partnering. The architect role is relatively new in many organizations, yet the work was being done, more or less well, by people in other roles. This puts the architect in a situation where the architect's responsibilities overlap with those of others, and where they face turf-protectionism from at least three different constituencies: developers, managers and business analysts (or requirements analysts). Agile approaches try to put these back together, both in terms of the roles (eliminating hierarchy) and process (eliminating the "waterfall"), and this works just fine for small co-located teams. For bigger teams, especially those that are not co-located, we have to work harder to figure out roles and divvy up the work so that it can proceed effectively.

So the architect is taking away technical decision responsibility from developers. Hopefully, the architect is leading a consensus-oriented decision process, but even so, too many voices slows progress and not everyone can be satisfied all the time. We have to accept good-enough, or we will never be done! Reality check one!

And the architect is not taking away all technical decision responsibility. In a minimalist architecture approach, the architect defers all decisions that can be made at more local scope of responsibility to the owner at that scope (e.g., to the component owner which might be a tech lead for a complex component, or might be a developer, for a more narrowly scoped component).

4/19/06 Requirements, Innovation and Architecture

Ford's Model T and the Douglas DC-1 changed the face of transportation because their inventors innovated beyond what people generally imagined they wanted or was possible. Though the Segway uses revolutionary technology, it has not been transformative in the way that Kamen promised investors. Not every product or application we work on will reshape the landscape of competition in the way that these innovations did, or promised to.

We don't get to work on revolutionary products, or even new products and services, all that often. But even when we are working on incremental changes to existing products and services, architects have a role to play in innovating to create compelling value and differentiating advantage. Ideas will come from a variety of sources: the strident voice of the dissatisfied customer, the eager voice of the customer on the bleeding edge, the fading voice of history and alluring whisper of the future, and the ingenuity of the design and development team.

The architect needs to hear these voices, at least some of the time, to be inspired and inspiring. They are the source of stories that will shape the vision of what is possible, and speak to and win the hearts and minds of sponsors and developers, marketing and project managers, and all the others that play a role in bringing innovation in process and product to realization and eager adoption.

As architects, we need to constantly balance strategic, long-term competitiveness with short-term pragmatics. We need to be the watchdog of complexity and risk, and we need to lead the organization into the future with differentiation where it is valued, and parity where it is not. 

When our business decides to modernize IT, we have to decide how much of that initiative is about differentiation and how much is about simply being on a level playing field with our competitors. If it is "core" in the Moore sense (i.e., the edge where we compete and need to have and hold compelling competitive advantage) then we need to innovate to create distinction. If it is "context," and we only need to maintain parity with others in our industry, then we need to figure out what that means over the horizon of the technology investment so that we don't invest only to find ourselves behind and playing catch-up even as the replacement technology is being rolled out.

When we decide to replace the platform for our product line, we need to be careful not to simply create a "cleaned up" version of our current systems using more modern technology. We do have to do that. But we also have to think strategically about how to differentiate into the next era of competition in this product space. Architectures are around for several years (if not decades!), and we only get to substantially reconstruct the platform once every few years if our management team is disciplined about an investment strategy that refreshes our product capabilities every few years.

Yes, as architects in IT and as architects of products we have to think in terms of differentiating capabilities (function and property; service and quality of service; etc.) and we have to think about where we need only accept good enough to be an effective player in our industry. We need to find opportunities to innovate where it matters, and be disciplined and restrained about taking on complexity where it does not matter. We have to be strategic thinkers, and we have to translate that thinking into technical decisions, so that a clear sense of strategy shapes our choices.

We tend to want to do everything better, but some things matter more to our success. The architect needs to find the line that distinguishes what matters, from what does not. The architect, like the strategic manager, has to work toward compelling advantage not just short-shrift wins.

Architects need to be great at strategy, and need to pay particular attention to strategy and innovation, so here are some more readings on strategy:

• Alfred, Charlie, "Value-Driven Architecture: Linking Product Strategy with Architecture," June 2005. http://msdn.microsoft.com/architecture/journ/default.aspx?pull=/library/en-us/dnmaj/html/Jour5Value.asp 
• Alter, Allan E., "Innovation Makes Emerging Technologies Pay Off," CIO Insight, June 5, 2005. http://www.cioinsight.com/article2/0,1540,1826516,00.asp 
• Baker, Edward H. and Ellen Pearlman, "Innovation Takes More than Inspiration; it Takes Investment, and Persistence,"  CIO Insight, January 6, 2006. http://www.cioinsight.com/print_article2/0,1217,a=169616,00.asp
• Malan, Ruth and Dana Bredemeyer, Architecture Strategy, http://www.bredemeyer.com/ArchitectingProcess/ArchitectureStrategy.htm
• Malan, Ruth and Dana Bredemeyer, "Enterprise Architecture as Strategic Differentiator," Enterprise Architecture Executive Report. Cutter Consortium, June 2005. You can download a complimentary copy from http://www.cutter.com/offers/strategic.html
   
• Also, see Strategy Books on the Resources for Architects Recommended Books list, and the section on "Vision and Strategy" on the Resources for Architects Bibliography page.

4/21/06 Differentiation and Business Imperatives

The architect needs to work on differentiating, compelling value propositions that deliver competitive advantage. And the architect has to work on resolving what the business must do, simply to be in the game. What are the business imperatives? What are the challenges involved in good enough to be a player and what are the challenges involved in creating distinction from competitors? Distinction in identity, and in value delivered.

The strategic direction and the imperatives of our day-to-day survival translate into drivers that we have to pay attention to as we create or renovate our architecture.

4/22/06 Constraints and Delight

To pick up the train of thought. We need to delight our customers/users, providing an experience that gives them value. We need to ensure that the total cost of ownership, including the cost of quality and in all its guises from frustration and time wasted to the cost of rework and upgrades, is minimized as best we can. And we need to do so within the constraints of our user environment and our development environment, constraints imposed by partners in the value chain, constraints that come from our technology, and so forth. These determine the parameters within which we need to work: development timeframe and cost, what computing resources we must assume, memory footprint constraints, what systems our system must interact with, what components we are obliged to (re-)use, and so on.

All these factors determine the challenges we face as architects, which we have to weigh and tradeoff, to achieve the system goals relating to the quality of user experience, the cost of ownership for the user and the lifecycle costs for the development organization.

Put like that, it seems like a tall order. That, at least, is the best we strive for. The more complex the products and solutions in our competitive space, the more ambitious we are driven to be, to create that competitive edge.

Architecting is about finding the best possible approach to addressing these challenges, recognizing that these forces interact, sometimes in unknown and even unknowable ways.

4/24/06 Architecture Challenges

As architects, one of our most important jobs is to identify and resolve the most significant challenges for the system under design (whether it is a new design, next generation design, or design for renovation and enhancement of the current generation system).

Just being a player in our industry means we face a set of challenges because the state of practice keeps evolving, and if we stagnate we get behind. Then we have to modernize just to get back to a level playing field.

In business, in the arenas in which we actively compete, we have to do more than that—we have to differentiate along one or more dimensions. We need to provide product features or services that stand out from the plethora of other options customers could go with. It is not just about offering some features and attributes that are not yet in our competitor's products. We need to offer some real and compelling unique value; we need to "delight" our customers (see the Kano discussion on our Resources for Architects Strategy Process page).

The architect needs to balance the need to differentiate with the lifecycle cost of every feature and every aggressive quality attribute that is pursued. 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, some level of security, scalability, disaster recovery, in many systems are threshold attributes not our avenues for differentiation. But we must develop strategies (authentication, encryption and firewalls; load balancing; failover, etc.) to address these challenges. And these strategies have to be implemented, along with every function or service. Just delivering the base level of features and qualities is challenging, given 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.

Moreover, the architect needs to play a role in increasing what we are able to do, and increasing the value of what we attempt to do, by focusing. 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 to ignore—those are key to success.

Thus the architecture challenges arise from what we need to do because we are in the kind of business we are in, and from what we need to do uniquely well to create competitive distinction. These challenges will come from the environment, from our users and what they care about and are trying to do, and from our business, what we care about and are trying to accomplish and what we have to work with to get there.

4/24/06 Architect Skills: Persuasion

Thanks to Kevin and his Architect's Linksblog, here is a piece by Guila Muir on persuasion, in particular, presentation and persuasion titled All Presenting is Persuasive.

Kevin's Linksblog is already a useful resource. I visit a few times a week to see what that architect maven has scouted out for us.

4/24/06 HelpMatch: VolunteerMatch

I was reading essays on Scott Berkun's site (great writing, and poetic use of photographic image). Anyway, Scott has a link to VolunteerMatch. I had come across this site in my early searches to find a way to help those impacted by Katrina, but it didn't do what I was looking for in terms of matching donations of goods to those who need them, and I moved on.  Anyway, it isn't HelpMatch, but it covers some of the territory (volunteer services).

4/24/06 Lead, Follow or Get out of the Way or Goodwill is the Real Silver Bullet

One of Scott Berkun's essays is titled "Why You Must Lead or Follow." I strongly recommend it to architects. Dana and I designed a tutorial for the 2001 DCI Enterprise Architecture Conference titled How to Lead, How to Follow and How to Get Out of the Way.  Ever since, we have had a section in our Role of the Architect Workshop by that title. It is closely related to our notion that goodwill is the silver bullet that is able to slay the software dragon. When something is complex and big enough that it takes a good many people to get the job done, we have to divide and conquer. Then we need to get all these people on board, enrolling them to contribute the best they can to this thing we are creating. Someone has to lead, but there is no leading without following. Good following is following with a spirit of goodwill, not a spirit of resistance and resentment. In some organizations, the culture of consensus has become an inverted culture where everyone colludes not to lead, because there is an unspoken universal "if I cannot lead then I will not follow." This is not goodwill. This is accepting decisions by committee because no-one is willing to abdicate the authority to make the decision.

You are probably accustomed to hearing Brooks quoted round about now. Scouting the web for the quote I wanted to use (ok, so it wasn't quicker than walking over to pull Mythical Man-Months from our business library which is all of two rooms away!), I came across a report on Fred Brooks' Turing lecture in 2005. It is a good read. And if you're reading this, you're probably a quick reader so, it won't set you back but a few minutes. I liked the part about the shampoo and the farmer.

Back to conceptual integrity and architecture as by a single mind. In the anniversary edition of Mythical Man-Months, Brooks revised his earlier insistence on a single architect to an architecture team that creates an architecture as if of one mind. Most things have simply become too complex for a single superb developer, or even a handful of superb designer/developers.

Architecture and Complexity driven by Big, Hairy Audacious Goals

Consider the HP copy/print/scan device selling at Sam's Club for $45 before Christmas. (I bet Santa got to look good in many more households than just mine in 2005! ) Let me say it again, without the Santa distraction: a copy/print/scan device for $45! Ok, so what are the architectural concerns here: big functionality, cheap hardware. So we're talking memory constraints, and we're talking production costs that are minimal, and that doesn't even leave room for R&D. There's no business out there that can produce all that functionality and sell it at $45 a unit, even if they are making their money on the ink!  The development costs have to pushed down so low there's not a whole lot of R&D expense to amortize over each unit sold. What am I saying? One, given the functionality of this device, it was not created by one or even a handful of developers, not from scratch anyway. And two, you can't have 400 developers create this thing and then sell it at $45 a pop. You have to be amortizing your development cost over other models. OK, so the architectural challenges involve not just the low end, cost/memory constrained devices but other devices with enhanced feature/quality/performance demands. Now we're talking not just about complexity in terms of a feature set, but complexity in terms of scaling across feature sets and memory footprint, form factor, performance considerations, and everything else that makes the various models in the product family distinct from each other and from their respective competitors.

COMPLEXITY is here to stay, and yet complexity is so successfully managed that we get a steady stream of unexpected breakthroughs in what we can do with ever less time and resources. Yeah, we have a lot to gripe about on our bad days, but in truth, we are getting a whole lot of good work done with big projects and ambitious goals. We sell ourselves, as an industry, short by focusing on the missed deadlines and headliner glitches, when the great tapestry of innovations of the past few decades is astonishing. Truly astonishing! Software has transformed our lives. We must have been doing some things right. And most of those things are being done on pretty big projects in aggressive timeframes. Sure, in many cases it has taken heroic stints to pull it off, and the code suffers, and then the organization suffers because we can sustain heroism for just so long before we, or our families, snap.

We are ever more demanding of our products and services (Collins and Porras used the term "big, hairy, audacious goals," or BHAGs, in their 1994 book, Built to Last). We must extend the capability and utility envelope with every release, in timeframes driven by intense global competition. Complexity, and big projects, are hard to get away from.

We just have to get better at architecture, and more clear about the role of architects. And then we can XP on the small, and fake small in the context of big projects through architecture. Then everyone can be happy, go home at 5pm and play with the kids. Yes, and then still have enough energy to work on HelpMatch for an hour instead of feeding on that brain candy otherwise known as TV, before going to bed at the same time as all those folk whose careers promised quality-of-life rather than computer-generated performance feedback. Let's face it, no spouse is more seductive than a piece of code that is not yet quite working, and the gratification from getting it working is hard for mere mortals to match.

On the subject of big organizations, architecture teams and decision making, there is a nice vignette by David Emery of MITRE Corporation on the SEI Software Architecture Essays page, titled "Architecture Team Organization Soviet Style."

References:

Missed deadlines:  Vista

Headliner glitches:  IRS modernization, Palmdale air traffic control (and NBC's version).

4/25/06 Lessons from Building Architecture

I came across the ArchKidecture site (architecture for kids), and it has this story about Bruce Graham, architect of the Sears Tower in Chicago:

"Bruce Graham, architect at Skidmore Owings and Merrill, told the story that when he was trying to think of a design for the world's tallest building (at the time), the Sears Tower in Chicago, he was playing with a bunch of cigarettes at his desk. Soon, he realized that if you bundle up the cigarettes, they made a stronger tower than a single cigarette. He then considered that the building itself would be a bundle of towers (nine in all) and they would be able to withstand the forces of wind that might otherwise blow over such a tall structure."

And here's their piece on what architects really do:

"According to the American Institute of Architects aka the AIA, an organization that a HUGE number of american architects belong to:

Architects clarify and define your building needs. Through a process called programming, architects can completely examine your specific requirements, your budget, and building site to help define the scope of what's to be built. Architects solve problems creatively. Architects are trained problem solvers. Not sure how fast your organization is going to grow? An architect can design a space that meets your needs today, and that can be adapted for tomorrow. Have a limited budget? Architects look for ways to make your project cost effective and propose ways to get even more for your investment than you imagined possible. Architects see the big picture. They don't just design four walls and a roof—they create total environments, both interiors and exteriors, that are functional and exciting places in which to work and live. Architects manage your project. From site selection to move-in, architects act as project leaders. They manage and coordinate key project elements, while you focus on your organization's activities."

4/25/06 Architects and Models

Why did I highlight the Bruce Graham piece? Models, including visual models and physical mockups, are important tools of our trade, yet they are not used enough. In our field, the tendency is to do our thinking through code. We tackle a problem, have the joy and satisfaction of getting it working, then expand the scope. But code is expensive. As the code size grows, more is invested: time and money, egos... So we tend to tweak and short-cut and kludge our way to good enough. We don't throw the thing out and start over. Partly, our customers don't see the mess, only the results of the mess, and by then they have to decide whether the gain is worth the pain. Wouldn't it be a different world if customers could see the code structure? Or if designs had to pass inspections, and construction projects had to pass inspections at various phases—like building inspections before the cladding gets puts on the walls and hides key structural details?

At any rate, not nearly enough modeling gets done. We haven't reached the point where, as an industry, we value and expect models before (and during) coding. It has been more than a decade since a program manager for a next generation product solution effort plunked down a pile of models on my desk and said "I don't know what else this means, but our architects have done a lot of work. I suppose it's a good thing." This from someone who had been very influential in the software quality field, before moving from QA to program management! Working code is what we know how to value. Even if "working" is a temporal illusion. Still today, there is the same nervousness around time spent modeling. And the same cowboy bravado associated with cut-it-on-the-fly development.

In the shampoo business they use computational fluid dynamics to model the viscosity of the fluid. In aircraft design they use wind tunnels (and CFD and more). In software we just start to build. Why do we think software is so hard? Because we make it hard! At least, we make it harder than it needs to be! Jumping into code makes us feel good—we're working! And then we're working, and working, and working, with no clear end in sight!

For those who push back, and say we need to incrementally deliver working code to our clients so they can get a better sense of what they want, I say, do the first levels of exploration much more cheaply—use models and mockups. And always think about just how much "tweaking" our clients can afford to make! Yes, we need to take the user goals and user experience into account. A poor use model is inexcusable. If there are a small number of users, and the software does not meet their needs, that is inexcusable. If there are a large number of users, and most find it unwieldy, frustrating or off-target, that is inexcusable. We need to identify the failure modes and address them appropriately. We need to address them appropriately given the state of our art. But we don't take advantage of the state of our art nearly enough.

Yes, technology, user expectations and our business needs are moving so fast that we have no steady ground under our feet to depend on. Our past experience only serves us so well, and experience is the best we have to go on. So we will have uncertainties. And we will only be able to resolve some of those uncertainties by actually experimenting—writing code. But the whole project shouldn't be an experiment! Architects need to understand where the uncertainties and risks are, and create a strategy to explore and resolve the uncertainty and reduce the risk. This means that architects should be able run skunk works projects ahead of the bigger development effort to scout out approaches to addressing the big challenges. And it means architects need to create models. Identify architectural imperatives and goals. Visualize the system. Get a sense of the risks. Identify strategies. Visualize approaches and perform thought experiments. Identify focused coding experiments and get a better sense of estimates and budgets and how the thing will really work. And work with the development team throughout the development of this and subsequent releases, so that the architect learns and the architecture as represented and the architecture as built match and evolve in understood, rationalized ways.

Architecture and Buildings

The Empire State Building was built in just 14 months (16 if you include site excavation). When completed in 1931, it was the tallest building in the world (at 1252 ft with 102 stories), and so it remained until 1972.  Total construction time: 7 million man hours; Work force: 3,400 during peak periods (from New York public Library facts about the Empire State Building).  The building was completed about a month and half ahead of schedule and about $5 million under budget (from the Emporis Buildings page on the Empire State Building).

Oh, and get this: "During planning stages the construction death toll was estimated to be one worker per floor, or over 100 workers overall. However, only a handful [5] of workers lost their lives during construction." (from the Emporis Buildings page on the Empire State Building) These photos of the construction illustrate the dangers.

The technological complexity was huge! Unprecedented things were being done: at 102 stories it was 25 stories taller than the Chrysler building the next tallest building. The organizational complexity was huge—the co-ordination necessary to have 3,400 workers (at the peak) contribute effectively to go-forward work is mind-boggling. 7 million man-hours could not be usefully applied in just 16 months without a grand plan and lots of detailed plans (incrementally delivered); without the big-picture and with structural details ironed out in advance of putting the pieces in place. You don't get to go back and refactor the key structural elements of a 102 floor building!  

It just could not be done without architecture, just as truly as it could not be done without excellent project management and good, daring construction engineers and workers!

Architecture and Software

And we don't attempt projects of anything like this magnitude without software architecture either. Many organizations that build complex systems have had the architect role in place for more than a decade or two. Most create a conceptual architecture diagram to launch teams. But if all we do is sketch out a high-level system structure which designates the components (or subsystems, modules, elements) and their relationships, and assign the components to owners, and move on to coding without consideration for system design issues, then we can expect what we get: a kludge. The conceptual architecture is a key architecture model, highly useful in work partitioning and system understanding. But it is not enough. Not for systems of reasonable complexity and not for systems that we anticipate will be around through a series of releases.

As the Empire State Building story illustrates, this does not have to mean waterfall development! Using the "fast track construction process," construction began before the designs were fully complete, and the schedule dictated that each section of the building process overlapped.

4/25/06 Architecture and Strategy: The Grove

An email from Thomas Sibbet announcing David Sibbet's new Graphic Facilitation manual reminded me that the Grove products and services around visioning and strategy are superb. We have integrated their approach, and have come up with some of our own graphic templates to supplement, and sometimes replace, some of the Grove templates. But we strongly, enthusiastically recommend that all architects (and managers) take the Grove facilitation and strategic visioning workshops and/or buy the manuals and guides. We recommend them because we know, from personal experience, that the Grove graphic approach is powerful.

To get a sense of the power, take a look at this graphic vision the Grove did with National Semiconductor! and the AAA MemberPoint Roadmap.

4/26/06 Career Ladders: Architect and Engineer

Many organizations have had a dual career ladder in place for a long time: allowing technologists a path to gain recognition and salary benefits just as those on the management track do. Now we have to think more in terms of three ladders. Architects are not just engineers higher on the career ladder! Architects have a different role and responsibilities, and need different skills than simply being superb technologists.

We still need a development path for engineers, because we need to be able to attract and retain superb developers, and give them recognition and reward. Engineers (programmers, developers, whatever title you and your organization prefers) are vital to success of projects. Great engineers are relatively rare. We need to nurture and grow great engineering talent to get great products out.

And we need a development path for architects. Having such a growth path allows:

4/26/06 Architecture Documentation

I got an email ping asking for help on architecture documentation. It caused me to pull together some links that are useful in this area. Here's some guidance on the architecture document:

• Architecture Documentation

• HP's Architecture Document Template

• IEEE 1471 Recommended Practice for Architectural Description

• SEI's Architecture Document Template

And here is some guidance on creating an architecture:

• Software Architecture Action Guide Book (draft)

• Visual Architecting Process

And for background on what software architecture covers:

• Software Architecture: Central Concerns, Key Decisions
• Minimalist Architecture
• What is Software Architecture

4/27/06 Architect Skills: Grove Graphic Guides

The Grove has a truly amazing, outstanding web site. And besides being a visual treat, it is one of the most useful sites for architects wanting to ratchet up their visioning, strategy, communication and facilitation skills! The only site that comes close is ... you fill in the blank and tell me!

Here are some must-see points on The Grove web site:

• Demonstration of Grove Graphic Guides in a meeting. If you click all the arrows, so that you move through the various facets of the demo, including all the meeting situations, you'll see all the guides and get a description of the role they play.

• Watch Dave Sibbet's video clip Introduction to Graphic Guides online

• Grove success stories shows examples of what can be done with graphic communication.

And do take a look at these great Grove products:

Grove Graphic Guides and the Digital Guides (CD) with Powerpoint templates, and Graphic Guides Posters

Facilitation manuals:

• Graphic Facilitation: new!
• Best Practices for Facilitation: 176 Tried-and-True Facilitation Practices 
• Principles of Facilitation: The Purpose and Potential of Leading Group Process 
• Facilitator’s Guide to Participatory Decision Making 
• I See What You Mean: Graphic Facilitation Overview

Help with visual expression:

• Visual Thinking

• Pocket Pics

• Fundamentals of Graphic Language

4/27/06 Architects and Persuasion: Presentation Skills

Presentations aren't all an architect does to communicate, inform and persuade. But presentations are an important vehicle, and it helps to become more self-conscious about our strengths and weaknesses, and avenues for improvement, in this area. Even chief architect, Bill Gates, takes a pounding on the visual communication meter! Garr Reynold's essay titled Bill Gates and Visual Complexity is a good starting point, but do take a look at his other essays.

Garr Reynold's recommends a number of books I already have, but I'm going to get Beyond Bullet Points by Cliff Atkinson, and Going Visual: Using Images to Enhance Productivity, Decision-Making and Profits by Alexis Gerard, Bob Goldstein and Guy Kawasaki.

4/28/06 Software Architecture Diagrams

I was looking for the blog post that alerted me to Garr Reynold's Presentation Zen blog... I didn't find it, but came across a post by Alex titled The Joy of Software Architecture Diagrams. He concludes "Anything else and you run into the fact that building software is a social process and getting lots of people to move in the same direction is just plain difficult." 

There are some nuggets out there in the blogosphere.

4/30/06 Goodwill and the Real Silver Bullet

Brooks, and many after him, claimed there is no silver bullet that will improve software productivity by an order of magnitude. But lack of goodwill is a show-stopper, while highly productive teams achieve far more than the average bunch of people largely because they work in a spirit of goodwill. There is time for divergence and exploration and openness to great new ideas, challenges to those ideas, and more new ideas. And there is time for convergence and agreement on direction and quick execution. All these creative phases require goodwill. Everyone's head is in the game. There is no abdication of a responsibility for energetic, creative contribution, just because different people get to play different roles, including leader and followers.

What does goodwill mean? If you are an IT architect, and your CIO seems to be changing direction every couple of weeks, does goodwill mean you change direction every two weeks? Or does goodwill mean you try to understand what environmental changes your CIO is responding to, what about your business context has changed and is making it hard for your CIO to set a consistent course? When you understand the context, you will be able to make a contribution to finding and setting a more solid direction. Goodwill means working from the assumption that people are trying to do their best. It does not mean you put your good sense aside and blindly do what you are told to do. But it does mean trying to see other perspectives and figure out what the bigger driving forces are, so we can get out of our own box of preconceptions and predilections. Maybe once we have done this we will still find no common ground. But chances are, we will at least find the compelling value, and the language and images to express these, that will help our boss or leader set a better path to higher value.

Goodwill: "Architecture as Business Competency" (.pdf) by Ruth Malan and Dana Bredemeyer, January 2004.

4/30/06 Me Blog?

I have been asked, and yes, I have thought about, blogging rather than "journaling." Blogging has rapidly gained considerable momentum, and Blog searches, Blog ranking, and RSS feeds all have value to add.

Personally, I strongly prefer self-initiated excursions into the information hyperspace. When I come across a writer whose essays and papers I respect, I return to their blogs or websites when I have the bandwidth and inclination to follow up on their topic of discussion. This is one of the means by which I protect myself from the information explosion. So I imagine that most people don't have the time to be notified every time I write a little something.

As for Blog ranking, I don't think I would make it noticeably high on blog rankings anyway. Being horribly contentious and getting everyone riled up seems like a quick way to rise up in a ranking system that uses either number of links or number of comments as the popularity meter.  Such a number has no outrage indicator! But I could not stomach that stratagem.

That said, the day is (fast?) approaching when I shall have to hang out a shingle in the blogosphere, since that is where much of the popular action is.

<9/13/06: Azubuko Obele has a post titled "The Too Much Information Problem," which I came across after reading "The Problem is Choice." On the question of language, Buku is fittingly well-spoken. Whenever DSLs come up, I'm reminded I miss Forth (yes, I started out on embedded systems eons ago when we still used assembler and Forth). So I googled "DSL Forth" to see who else was making the association, and came up with a rather nice post by John Mitchell, which I pleased to come to encounter by way of John Reynold's comment, which alludes to Forth.> 

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

I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog

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