A Trace in the Sand
by Ruth Malan
12/4/06 And I thought November was busy!
Dana and I have 4 back-to-back architecture workshops, and all the year-end accounting (the bitter pill of running a "boutique" consulting business) and other day-to-day consulting and client relationship "work" (the joy of being in this field).
Well, December will likely be a quiet month for this creative outlet, so you might like to look instead at "back-issues": November, October, September, August, July, June, May, April, March, February.
12/19/06 Geri Winters Architecture Course at CMU
Geri Winters posted a kind reference to the Visual Architecting Process and the Resources for Architects website (www.bredemeyer.com) to the Visual Architecting Google group. You will find the slides from Geri's CMU course on Software Architecture at http://www.andrew.cmu.edu/course/67-307/.
This has been the season for kids bringing viruses home from school! As if flu and chickenpox wasn't enough, we all had to suffer by turns through stomach flu. I've never pounded my head against a brick wall, naturally, but they say it feels good when you stop. I can relate; stomach flu is one of those things that make one deeply appreciate good health! So, I wish you all great health and safety through the holiday season!
In the meantime, I'm learning to appreciate this holiday as one where dreams are made, turning up the engine of commerce and keeping us gainfully employed! I have to marvel at the super-heroes of this frenzied shopping season: UPS is clearly in cahoots with Santa, but none can surpass the logistics miracle of Zappos. Granted, from the distribution center in Kentucky they are but one state away from us in Indiana, but when shoes ordered on Saturday night arrive on Monday afternoon with free shipping, one has to marvel at the way Zappos has IT and physical logistics working together to beat the industry! I hear Zappos mentioned enthusiastically (and loudly) by men in Starbucks, in the airport, in the bookstore! Men are coming out of the closet about their love-affair with shoes—yes, I'm serious! Zappos has tapped into something latent, and the success story is speaking its way across America!
And I have to say this again: the Zappos success story is as much about software as it is about market sense and physical logistics—that they have down pat, but it is the enterprise system, the way they put together people, process and technology, that is the hallmark of their success. I have found delight just reading the feedback from Zappos customers posted on their site; it is enchanting to find a company that makes people happy enough to take the trouble to say so! Happy customers of a business that is based on the internet! A business who's primary customer face is the face painted by software. A company who's back-up face has the voice of a real person and the brain of a computer, providing the person with intelligence to handle each query or issue sensibly. Yes, I do think this is a case worth studying.
Architects teach me through their successes and through their struggles. I truly like most to learn from successes! I am inspired by architects who act from the orientation that attitudes shape the course of events and so act with positive personal energy because they know that will generate reciprocating, enthusiastic, collaborative partnerships. And I am inspired by companies that surpass others in their ability to deliver delight; goodness gracious, who would ever have thought the word delight would be used in conjunction with shopping for shoes, and on the internet at that!
So, how do we deliver delight? That should be our mission as architects: to find the avenue to delight. Along what dimension do we use technology (along with customer-respecting service) to deliver the experience that delights, and along what dimensions do we accept parity to make our systems affordable and manageable from the perspective of every turn that complexity takes? Yes, each quantum of value we add, comes hand in hand with complexity and architectural challenge. As architects we have to find the balance that differentiates, the balance that delivers compelling, and in important ways unique, value at a price that is justified by the perceived utility and competitor positioning.
Across diverse industries, from embedded systems to financial services to retail systems including web commerce, the software architect needs to work in partnership with others to find these vectors of value. Business people, marketing, hardware architects, all need to recognize the key role software plays in delivering differentiating value. And software architects need to recognize that they contribute an important perspective; not the only important perspective, but one that needs to be integrated to find the full opportunity for the business.
So, 'tis the season to find inspiration that will invigorate you as you turn your thoughts to the New Year. I find inspiration in this season of giving; the children in my kid's class have raised over $1000 to buy gifts for a local family that needs this grace, and to help children at a school in South America. My daughter is working every angle to earn money to buy her brother a dog for Christmas because she knows that would overflow him with joy! Her idea tonight was to write and sell poems—here's one she priced at 56c. Last week it was drawings. I told her about John Wood (if you've read the book, you'll know what I'm talking about).
And I find inspiration in the businesses that distinguish themselves, taking pre-eminent advantage of this season of giving and the grace that comes with acts of kindness and generosity.
Yes, yes, I know there's a severe downside to the production of material goods... sigh... but also an important upside in life-sustaining work. The intellectual satisfaction and personal gratification of working at the frontiers of innovation mark us as especially fortunate! This is the era where wealth has spread sufficiently to create a class called the "mass affluent." To me, what is more important is that this is the era of mass creativity! The opportunity to blend science, engineering and art to innovate and create is not relegated to a prestigious few; rather, the opportunities are huge, and increasing around the globe.
mentioned the www.bredemeyer.com website, but I'd like to give you some more specific direction on
resources you will find there to help you get traction:
12/26/06 Collaborative Partnerships
Being a great architect is very much about being a great collaborator. When I scan across all the great architects I've had the good fortune to work with, one characteristic stands out: great architects are smart, yes; they can do amazing things on their own, yes; but they don't! They work well with others. They partner well. They collaborate. Complex products and services are created by people—often a good many people, from various disciplines, with varied contributions to make. Ok, that's a generalization, but it is a generalization that applies to us because architecture really comes into play when what is being created is too complex to be built by lone tech-cowboys.
Collaboration is a kind of generosity; we must give not just take. We give up some ownership of ideas, but we gain better ideas. We give up some independence, but we gain stronger buy-in and more champions for the work we care about having succeed.
So who do we need to collaborate with? Generally, architects need to partner well with business managers and future product marketing on strategy, marketing or business analysts on requirements, and engineers (software developers, QA, hardware and infrastructure architects and engineers, etc.) and project managers in the development community on building the product or service. Architects need to be good at creating effective partnerships and breaking down the turf-protectionism they face. Sharing responsibility and credit is key to creating an effective cross-functional team.
Lead by example, using generosity of word and action to lay a strong foundation of goodwill. Of course, acts of generosity feigned to manipulate will be seen for what they are. Great leaders need to know themselves, and listen to others. By paying attention to both, you will find the words and the actions that will allow you to lead by setting an example of genuine acknowledgment of good contribution, and sharing—not taking—credit for collaborative work.
12/29/06 Multi-Functional Teams
I started out my career as a programmer. I was one of those developers who was a super-productive, hyper-achiever who demolished teams and supplanted them. After several years in software development, I went to grad school and then to work in the Software Lab at Hewlett-Packard Laboratories. I "grew up" at HP. There I learned the behaviors and the value of effective multi-functional teaming. In part, the systems we tackled at HP were much more complex, and in part, the competitive landscape demanded truly effective multi-functional teams to lead the market. We had talked about this at Stanford, but we lived it at HP. It became part of the way of corporate life for me; it was simply part of the background.
A combination of recent experiences has brought the importance of strong, collaborative multi-functional teams back into the foreground. We have been emphasizing that architects need to partner well across disciplines for more than a decade, without realizing that in some organizational contexts this is extremely difficult—sometimes painfully, abrasively so. It is difficult to collaborate in non-collaborative, turf-protecting, company cultures, and the culture of non-collaboration doesn't teach architects the important lessons I learned by "osmosis" in the HP culture of strong collaboration.
So I've been trying to become more conscious of what makes for highly effective, collaborative multi-functional teams. This has made me more aware of the behaviors that erode collaboration. So, for example, I notice it when tech leads/junior architects want to have the boundaries that delimit their domain of leadership clearly identified. They want to know where they own the decisions, and where the system architect owns the decisions, and they want these to be clearly separated. I notice it when business analysts or marketing people get anxious when architects seek to understand how the service or product will be differentiated in the marketplace. And I notice it when architects seek recognition for work that crosses these boundaries, working as the "hub" in a hub-and-spoke mechanism for gathering and transmitting information and decisions.
Architecture is only successful when a competitive product or service is built and fielded. This means an effective business and product strategy and effective strategy execution. Architecture translates from business and product strategy into technical strategy and leads the successful implementation of the technical strategy. Architects need to partner well; to be an effective participant in the teams creating business and product strategy, effectively lead the creation of technical strategy, and effectively lead the teams that implement the technical strategy. This means that the architect needs to work within difference spheres of intense collaboration, determining what value to offer in the market, and then getting to the best implementation of that value given organizational capability and constraints.
Collaboration means investing ones ideas, experience, energy, passion, and time with the expectation of a higher, but shared, return. If an architect does not lead by example, encouraging and then sharing credit for joint work, the architect will not encourage participation and not get collaboration. If the architect behaves in territorial ways, the architect fosters territorial behavior. Cultures have to be changed from within. If you want collaboration, you have to work collaboratively. Lead up, lead across, and lead within, leading by example, leading by demonstrating how to collaborate.
Availability is usually stated in terms of a requirement like 99.99% or 99.999% (5 9's) uptime. But what matters? One production planning system, in theory, has to be "always up" because it has users around the globe, but it is nonetheless taken down every day during the mid-morning hours (EST) to load data from other related applications; if not, it crashes unpredictably and for this system, it is better to be taken down (from the perspective of users) routinely, than to have it crash unpredictably. What we are willing to live with, differs from what we state we would be willing to live with, especially when the real costs (for more server capacity to alleviate the problem, or the cost of unpredictable failure) are not understood yet. Life is a matter of tradeoffs. Making these tradeoffs more apparent is where our architectural attention needs to be, especially when we are discovering and exploring the architecturally significant requirements that will drive our architecture design decisions because we will have to make choices, compromising some goals to achieve others better.
So, what are the threats and vulnerabilities we need to protect against? What is the source of the threat: planned upgrades or failure of hardware or software, or some geographical emergency? What is vulnerable? In the example above, manufacturing lines are at risk if sales forecast data isn't integrated and production plans updated on time each day. If it is sales volume for a web retail system, as another example, what impacts demand? What is the spread of demand across the day, across the weeks, the month, and the year? How does this differ by region? What events do we need to plan for? What contingencies do we need to be able accommodate? When do we expect to just let go and accept that the system will be down? If we look at our roadmap, what trends could lead to scenarios that are really good for our business, and what would that mean for the system? And what could be really bad for our business, and what would that mean for our system? If we understand expected patterns, and exceptional patterns, we can better understand the need for availability (where not being available means the system is down for all users) and when the system being down costs the most. Understanding threat, vulnerability and consequence helps us assess our contingency plans. These patterns also help us better understand the need for scalability (where lack of scalability can mean the system isn't available from the perspective of some users, or categories of users).
These are the classic considerations of risk planning: we need to understand threat, vulnerability, and consequence to understand the degree of risk, and then we need to put in place risk avoidance, mitigation and contingency plans appropriate to the risk likelihood and consequence. Yes, many of the non-functional requirements may be interpreted in terms of risk, which is really the downside of not achieving the quality requirement. So, when we try to get to grips with the security, scalability, availability, performance, safety, etc. requirements for the system, we are trying to understand the quality level we need to achieve, and we need to understand how failing to achieve this quality level impacts our business—that is, what are the risks we face if we fail to meet a threshold quality level? When we understand this threshold, and the downside for the business if we don't make the threshold, then we know what the requirement really is, when push comes to shove.
12/30/06 Happy New Year!
As 2006 draws to a close, I'd like to take this opportunity to wish you a safe and happy New Year, and a happy, deeply fulfilling, richly rewarding year in 2007! I look forward to continuing to learn from you all in 2007, and thank you for all the insights and questions that you have so generously shared with me in 2006.
2006 by Ruth Malan
I also write at:
- Bredemeyer Resources for Architects
By Topic (December)