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
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
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):
"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
"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
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
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
"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
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
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
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
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
- Provide consultation and leadership to
multiple project teams
- Ensure projects are aligned with the IS Strategy and compliant with technical standards.
opportunities based on technical knowledge and industry
- Serve as the technical application design authority on multiple projects
- Create macro
design (high-level design).
initial meeting with development lead
to agree on process for design.
- Establish regular meetings to review technical designs and provide mentoring and guidance.
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
- Meet new vendors to increase awareness of technology trends and assess the potential benefits to
technical standards and best practices, leveraging industry
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.
technical assessments for a range of circumstances:
application hosting, business acquisition, software vendor, etc.
- Develop a deep
understanding of Staples’ business
- Advise senior IS leadership (technical skills required,
- Build and
sustain commitment to IS strategy by mentoring lead developers and advising IS
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
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!
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
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?
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
[8/14/08: Eb Rechtin died on April 14, 2006.]
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
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."
"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
4/5/06 Architects: Building versus
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
4/7/06 Blogging as
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
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
"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:
"The last version of Netscape Navigator was famous for being
spaghetti code. I don't think any software engineer in their
right mind would intentionally try to get to the state in
which the NN team found itself - for the purpose of
performance or otherwise. ...
As I understand the situation, Netscape would have loved to rewrite major portions of their browsing engine much
earlier than they did, but they were in a high-pressure
browser war with Internet Explorer and felt it was only
feasible to keep tossing new features on top of the unstable
base [rather] than taking a year or two to reset by building a more
stable foundation. Indeed if you look a the modern
descendant of Netscape Netscape - Mozilla Firefox - it's
much more modular than NN and has a much better reputation
for performance, standards-compliance, and pluggability than
think the major factor affecting the quality (including
modularity) of systems like Linux and Firefox is having
experienced engineers design and implement the systems.
It's ... near impossible to create a great design the first
time you attempt a certain type of system. Look at Windows.
There used to be a bunch of unstable spaghetti (Windows
3.x/9x). Then MS created NT/2000/XP which was much more
stable, robust, secure, etc. Why did this happen? Because
they brought in some top notch engineers such as Dave Cutler
from DEC who had already created new operating systems
several times and had hundreds of person-years of experience
with what worked and what didn't work.
... Very few people in the world had experience with
creating a web browser so it was really learn-as-you-go. By
the late 1990s, the web standards had evolved a good deal
and the NN creators saw a lot of things they wish they could
do differently. But they couldn't because of the competitive
situation. When they finally took the plunge and could
re-write major parts of the application ... five years later
we have Firefox."
Posted by: Bill Higgins on January 31, 2006 on Nicholas Carr's blog
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
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.).
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
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
Use cases (or whatever vehicle is used
for requirements) capture the (intended) capabilities of the system in
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:
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.
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
and Requirements continued
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
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
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
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
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
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
- 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
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
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
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
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
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
Kevin and his Architect's
Linksblog, here is a piece by Guila Muir on persuasion, in
particular, presentation and persuasion titled All Presenting is
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
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."
Missed deadlines: Vista
Headliner glitches: IRS modernization, Palmdale air traffic control (and NBC's version).
4/25/06 Lessons from Building
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."
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:
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
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
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
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
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  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
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
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
4/26/06 Career Ladders: Architect and
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
such a growth path allows:
i. organizations to create a career ladder with associated
ii. hiring managers to set expectations for jobs
iii. teams to understand the architect’s role and
iv. evaluating managers to assess performance and set goals
v. managers to nurture and grow their architect talent so
they aren’t caught short in the innovation race
vi. architects to set personal development goals (Do I want to
be an architect at all? What level do I want to reach? What kind of
experience do I need to seek to get there?
vii. training departments to plan development programs for
architects at different levels (not just entry-level architects)
The whole notion
of an architect career ladder is, I think, helpful—not every manager
wants to or expects to become a top executive. They see that job as
requiring particular skills and responsibilities that come with the
territory of leading organizations and setting direction for large
numbers of people. It requires very special talent. And this is
similar for top architects. We shouldn’t, and architects shouldn’t,
expect that just years on the job, or specialist talent, should get
us to the job that has the most strategic responsibilities.
And then companies
can also see that the top echelon of strategic architects needs
extra special grooming and investment. We need to have careful
strategies for finding the talent, nurturing it, etc. It has
implications for candidate searches and for succession planning, for
leadership development, and so on.
business analyst team there might be some who have the technical
acuity that brings them respect in the developer community, and
gives them the technical insight to make good judgment calls on
technical strategy and enable them to see technology-driven
opportunities to differentiate.
application architect community there may be some that have the
leadership and strategic acuity to become superb enterprise
architects. And this will become MORE true if we give architects a
growth path so that they don’t have to defect to the management ladder
to have higher-level, higher-impact,
higher-paying job prospects!
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
And here is some
guidance on creating an architecture:
And for background on what software
4/27/06 Architect Skills: Grove Graphic
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
And do take a look
at these great Grove products:
Grove Graphic Guides and the Digital Guides (CD) with Powerpoint templates, and Graphic Guides
Help with visual
4/27/06 Architects and Persuasion: Presentation Skills
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.
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.
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
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.
as Business Competency" (.pdf) by Ruth Malan and Dana Bredemeyer,
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.
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.
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.>
2006 by Ruth Malan
Page Created: April 1, 2006
January 25, 2015