tag:blogger.com,1999:blog-41231734091202590262024-02-19T18:00:17.493-05:00Software ArchitectureBrian's musings on software architecture and development <br/>
(and other random thoughts)Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.comBlogger59125tag:blogger.com,1999:blog-4123173409120259026.post-31781132841494801282009-10-26T11:50:00.002-04:002009-10-26T11:52:32.510-04:00Application transformation targets enterprise bottom line with eye-popping ROIIs 80% of your IT spend committed to maintenance? Are inflexible and expensive legacy applications suffocating your innovation? Is the unprecedented economic climate demanding that you take a step back and ask, "Now what do we do?" If you're like many of us, you answer these questions with a resounding "YES". And you aim to do something about it by tackling one of the primary contributors to corporate lethargy... the legacy application.<br /><br />In his introduction of a compelling series on "the how and why of transforming legacy enterprise applications," Dana Gardner hosts Paul Evans and Luc Vogeleer from HP's practices for Application Transformation and Modernization.<br /><br />To whet our appetite, the gang speaks to a case study with the Italian Ministry of Instruction, University and Research (MIUR). The case study explains how they were able to achieve significant ROI - millions of dollars in savings - in only 18 months by employing a multi-faceted strategy that takes a "very holistic approach and looks at the entire portfolio of applications." Depending on parameters such as the usage of the application, the business criticality, the frequency of changes, cost, complexity, etc, the team selects transformation targets and techniques that create quick wins - immediate benefit. And the "ROI and the benefits from those quick wins are immediately reinvested for continuing the transformation. So, transformation is not just one project. It's not just one shot. It's a continuous program over time, where all the legacy applications are progressively migrated into a more agile and cost-effective platform."<br /><br />When it comes to large-scale transformation (or any large initiative for that matter), take note of the incremental approach focused on constant value creation.<br /><br />Check it out at <a href="http://www.it-director.com/business/change/content.php?cid=11613">Application transformation case study targets enterprise bottom...</a>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com16tag:blogger.com,1999:blog-4123173409120259026.post-30469586190011248142009-09-08T11:31:00.005-04:002009-09-08T12:11:08.788-04:00Effective Enterprise Architecture Capitalizes on EmergenceIt's been interesting to observe the response to Gartner's recent discussion of a "new" approach to Enterprise <span>Architecture</span>. In the <a href="http://www.gartner.com/it/page.jsp?id=1124112">press release</a> titled "Gartner Identifies New Approach for Enterprise Architecture," the analysts assert that Enterprise Architects must "respond to the growing variety and complexity in markets, economies, nations, networks and companies" by adopting a "new style of enterprise architecture" called "emergent architecture." And they describe seven properties that differentiate this "new" style from what they refer to as "the traditional approach to EA." While I find it curious that Gartner considers this a new approach, the analysts' guidance is sound and reflects the "state of the art" in EA leadership. In fact, it's the only style I've personally seen to be effective at all. Essentially, your EA practice should encourage the creation of an empowered organization capable of adaptive and goal-seeking behavior that maximizes effectiveness along the front lines of the business.<br /><br />In this light, let's take a look at each of their seven properties of "emergent architecture."<br /><br /><b>1. Non-deterministic -</b> In the past, enterprise architects applied centralized decision-making to design outcomes. Using emergent architecture, they instead must decentralize decision-making to enable innovation.<br /><br /><div style="margin-left: 40px;">I've heard about this "deterministic" EA practice. And I've also heard about unicorns. Every effective EA practice I've seen recognized its role as one of leadership - and context. One of the biggest drivers in business today is Agility - the need to respond rapidly to changing needs and opportunities. By definition, then, we are operating in a climate where the future is not pre-determined or predicted. As such, at some scale, the specific outcomes are obviously non-deterministic. But there's a huge risk of this property being abused (see <a href="http://blog.softwarearchitecture.com/2007/09/agile-is-not-make-it-up-as-you-go.html" target="_blank">Agile Is Not "Make It Up As You Go"</a>). As a whole, any organization with an EA practice absolutely has some destination in mind... some target. It's our job to create context and to provide leadership that helps the organization translate that target into actionable goals... and to adapt its way to success.</div><br /><br /><b>2. Autonomous actors -</b> Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents.<br /><br /><div style="margin-left: 40px;">Again, the idea that an Enterprise Architect could ever "control all aspects of <span>architecture</span>" is a farce. The power of an organization always lies with those that are serving the organizations clients - the business units. Our role in EA is to serve those people on the front line and empower them to better meet the needs of their customers - and at the same time advance the organization as a whole towards its targets. This is a role of leadership - not control - and I wrote about it in <a href="http://blog.softwarearchitecture.com/2007/09/leadership-secret-sauce.html" target="_blank">Leadership - The Secret Sauce</a>. Emphasizing the value of "collective intelligence," that post reminds us that we can "achieve outrageous levels of performance by harnessing the intellect and energy of the people." This also came up in <a href="http://blog.softwarearchitecture.com/2007/11/nurture-freaks.html" target="_blank">Nurture The Freaks</a> where we contemplated these words from Gary Hamel, "Going forward, no company will be able to afford to waste a single iota of human imagination and intellectual power."<br /><br /></div> <b>3. Rule-bound actors -</b> Where in the past enterprise architects provided detailed design specifications for all aspects of the EA, they must now define a minimal set of rules and enable choice.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYF2q80ItOw9dW_68ihyphenhyphenBz4SY9PKrFgzJQmUw0Y5XL11r5ziRgEoMlk76FOyHx4u4cn7RV2joNV5RHByhyphenhyphenBRSXmmVpoOFhMRY4lGCxSmgm54pLBxTu69DIhzPYuop_haP9yuMqRgsd6gw/s1600-h/guardrail.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYF2q80ItOw9dW_68ihyphenhyphenBz4SY9PKrFgzJQmUw0Y5XL11r5ziRgEoMlk76FOyHx4u4cn7RV2joNV5RHByhyphenhyphenBRSXmmVpoOFhMRY4lGCxSmgm54pLBxTu69DIhzPYuop_haP9yuMqRgsd6gw/s320/guardrail.jpg" alt="Guardrails" id="BLOGGER_PHOTO_ID_5379125183972872898" border="0" /></a><div style="margin-left: 40px;">It's a reasonably well accepted principle that an EA practice should never make a decision (or set a constraint) that could be left to the business unit or development team. In fact, enabling choice and encouraging participation are important vehicles for gaining buy-in and goodwill (see <a href="http://blog.softwarearchitecture.com/2007/06/governance-without-goodwill-is-dead.html" target="_blank">Governance Without Goodwill Is Dead</a>). This is yet another reminder of how we need to establish context by creating guard rails that keep the organization out of the ditch.<br /><br /></div> <b>4. Goal-oriented actors -</b> Previously, the only goals that mattered were the corporate goals but this has now shifted to each constituent acting in their own best interests.<br /><br /><div style="margin-left: 40px;">With the guard rails in place, responsibility for driving rests on the individual drivers, each in their own vehicle with both hands on the wheel.<br /></div><br /><b>5. Local Influences:</b> Actors are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No individual actor has data about all of an <span>emergent</span> system. EA must increasingly coordinate.<br /><br /><div style="margin-left: 40px;">There is a massive amount of information flowing through the modern organization, and the majority of it originates and circulates right on the front line where the dynamic nature of today's agile organization demands a high degree of "in the heat of battle" decision-making. This suggests EA add value by encouraging a broad community that is willing and able to actively contribute to and consume a real-time, high-bandwidth stream of communication. It's not our job to assimilate it all and make decisions. Instead, as individual consumers at the trough of the information stream, we help drive the information out to those who need it the most. I don't really like the use of the word "coordinate" here. We're only coordinating in the indirect sense. Perhaps this role is some combination of the Connector, Maven, and Salesman roles described by Malcolm Gladwell in The Tipping Point.<br /></div><br /><b>6. Dynamic or Adaptive Systems:</b> The system (the individual actors as well as the environment) changes over time. EA must design emergent systems [that] sense and respond to changes in their environment.<br /><br /><div style="margin-left: 40px;">This is one of the most important functions of the Enterprise <span>Architecture</span> discipline in a modern organization. We have a responsibility to bring a "systems thinking" perspective to the table and influence the design of flexible and adaptive systems - systems that have the ability to learn from and respond to their experience. When talking about systems, here, it's critical that we deliberately design this adaptive nature into our products AND our organizations. I'm happy to see that Gartner is beginning to recognize organizations as a type of "complex adaptive system".<br /></div><br /><b>7. Resource-Constrained Environment:</b> An environment of abundance does not enable emergence; rather, the scarcity of resources drives emergence.<br /><br /><div style="margin-left: 40px;">Most of us are operating under the influence of unprecedented economic conditions, and these times demand that we become more creative. In fact, <i>creative</i> isn't really the right word. To respond to the reality of the corporate climate of today (and tomorrow), we're going to need to be "clever" - adroit, nimble, resourceful, and mentally quick. The organizations that thrive in the future will be those that respond today by building a sustainable system of Agile capabilities that maximize the contribution of every associate.<br /></div><br />It's good to see Gartner lend its voice to the value of "emergence" in <span>architecture</span>. Gone are the days where a few of us at the top of an organization can see the future clearly enough to design a top-down response. For the past decade, nearly all the modern management and leadership literature has recognized that it's increasingly necessary to create empowered communities that respond to a vision with heart and passion. Organizations that adopt these principles are able to create, embrace, and capitalize on opportunities. As Enterprise Architects, our role is to help lead the establishment of that vision and create an appropriate context in which those opportunities are readily recognized and embraced with all the energy and intellect of the community.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-17097933117774010432009-07-28T20:00:00.004-04:002009-07-28T20:10:39.959-04:00Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3Dean Leffingwell, author of Scaling Software Agility, recently posted a series on the ongoing debate over "Feature Teams" versus "Component Teams" in the Agile community. Over the course of three posts, Dean does a great job of digesting the underlying concepts and considerations, and he ultimately recognizes there's likely not "one right answer"... That like most things in software, we're dealing with various shades of gray, and arriving at the right answer depends on smart people with good judgment.<br /><br />As he puts it:<br /><br />"Given the advantages and disadvantages to each approach - essentially the balance of immediate-value-delivery vs. architectural focus and potential for reuse - the agile enterprise clearly leans towards the feature team approach, as there can be no question on the immediate value delivery velocity benefits and the focus of the teams."<br /><br />"However, ... the answer is not that simple, and it's likely that a more balanced approach may be required."<br /><br />Whichever way you slice it, make sure your teams clearly understand the results they are accountable for - be they intermediate components or full-fledged product features.<br /><br />And for what it's worth, I strongly recommend you recognize the importance of organizing around the architecture. The alternative is allowing the architecture to organize around the organization, and that invariably leads to unintended consequences.<br /><br />Check it out at <a href="http://scalingsoftwareagility.wordpress.com/2009/07/22/organizing-agile-at-scale-feature-teams-versus-component-teams-part-3/">Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3</a>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-26784112113829359432009-07-19T15:40:00.002-04:002009-07-19T17:38:14.479-04:00Software Engineering: Dead?Over on Coding Horror, Jeff Atwood pointed us to a recent publication by Tom DeMarco titled, "Software Engineering: An Idea Whose Time Has Come and Gone?" As Jeff points out, DeMarco is someone who has shaped the thoughts and minds of the software world for a couple of decades, and when he unabashedly claims that "software engineering" is dead... well, that falls under the category of "things that make you go huh!?"<br /><br />Jeff does a nice job of putting DeMarco's comments into perspective and gives us all some things to think about. In particular, he encourages the focus on the "craftsmanship" aspect of our profession. This "passion for the craft" of software development is something many of us are enthusiastic about and spend a great deal of energy fostering within our organizations and teams. Jeff wraps it up nicely, concluding, "The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed. Everything else is just noise."<br /><br />I'm not one to abandon the engineering disciplines - and I'm pretty sure that's not exactly what Jeff or Tom are suggesting - but it's high time we all recognize that much of what we do is a "craft." Crafts are performed by people who care about what they do. When engineering attempts to take the place of heart and passion... we fail.<br /><br />Check it out at <a href="http://www.codinghorror.com/blog/archives/001288.html">Software Engineering: Dead?</a>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com2tag:blogger.com,1999:blog-4123173409120259026.post-53045864322508959362009-06-09T21:20:00.001-04:002009-06-09T21:20:07.168-04:00A Customer-Driven Architecture for Banks - Learning from iPhone Glenbrook Partners discusses a recent report from Javelin Strategy and Research that elevates awareness to the changing behavior and expectations among electronic banking customers in the "iPhone-era". Javelin explains that these customers will tend to be much more interactive with their financial institutions and will insist on a greater level of control and visibility. In some ways, this report speaks to the shift underway in application design, but it applies that transformation specifically to the needs of online banking. All-in-all, this is another example of how consumers are (appropriately) shifting into a position of even stronger influence over the applications we deliver.<br/><br/>Check it out at <a href=http://feeds.paymentsnews.com/~r/PaymentsNews/~3/A2a3I0MIbxY/a-customer-driven-architecture-for-banks---learning-from-iphone.html>A Customer-Driven Architecture for Banks - Learning from iPhone</a> Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-54315459393146007692009-06-06T13:30:00.001-04:002009-06-06T13:30:04.904-04:00Mistake Proofing and The Role of QA Roland Cuellar at LitheSpeed recently highlighted some of the characteristics of the QA role and the importance of rethinking how this role integrates throughout the development process to add even more value. Taking a position similar to what I propose in "One Team - Developers and QA" (<a href="http://blog.softwarearchitecture.com/2007/04/one-team-developers-and-qa.html">http://blog.softwarearchitecture.com/2007/04/one-team-developers-and-qa.html</a>), Roland borrows from some common "Lean" practices and encourages a deeper relationship with development and a focus on keeping defects out of the product right from the start. Specific recommendations include more detailed and interactive communications/partnership and the elevation of test cases to first-class requirements.<br/><br/>Check it out at <a href=http://lithespeed.blogspot.com/2009/06/mistake-proofing-and-role-of-qa.html>Mistake Proofing and The Role of QA</a> Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-131284774409194162009-05-27T17:50:00.002-04:002009-05-27T17:53:47.314-04:00Enterprise 2.0 Isn't a ChecklistThe FASTForward blog posted a nice perspective on "Enterprise 2.0" that deserves a look. Yes, this term (and the pursuit it represents) has its own set of risks, but it also embodies a shift in corporate climate that deserves clear focus and understanding. Summing up the purpose, Paula Thornton writes:<br /><br />So what IS Enterprise 2.0 focused on? People: tapping the human potential, helping to change the way business gets done by optimizing it not to the systems but to the people. Not shaping the people (via training and documentation) to the systems and the business, but changing the systems and the business to optimize the potential of the people.<br /><br />Under the heading of "How to get to 'Enterprise 2.0'", the article goes on to describe a number of the critical success factors:<br /><br />1. Truly Utilize Resources - Determine the typical scenarios for problem solving and recognize that departments or hierarchies do not hold the answers to business problems/issues: people do.<br /><br />2. Shorten Distances - Simplify all aspects of "doing" business. Repeatedly ask: What can we stop doing? Leverage what's working (from the perspective of all individuals impacted, not just those with "management" responsibility to execute) - bypass the rest.<br /><br />3. Embrace Organic - Organic is not chaotic. Nature has order, but that order is under rapid cycles of repeated construction and destruction.<br /><br />4. Shift Focus - It's not necessary or beneficial to make things "binary". Good designers are comfortable with the "squishiness" of heuristics.<br /><br />5. Shift Thinking - Design Thinking requires a different approach: it focuses on trying out multiple possibilities (fail fast) to test an algoritm - a problem statement. Many solutions fail because they either 1) started with the wrong question (the solution is the answer to the question) or 2) did not adapt to change the question (the problem statement) as more was learned along the way.<br /><br />6. Shift Culture - A company that has been optimized for "machine" design (command and control), will have a culture that reinforces such behaviors. Such a culture will undermine E2.0 potential. It will seek to eliminate the efforts as a "foreign body". A different culture is not a prerequisite, it's a corequisite.<br /><br />Some things to take note of.<br /><br />Check it out at <a href="http://feedproxy.google.com/%7Er/fastforwardblog/SYEL/%7E3/E_To5PWca_I/">Enterprise 2.0 Isn't a Checklist</a>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com1tag:blogger.com,1999:blog-4123173409120259026.post-3806347937090359342009-05-06T18:55:00.006-04:002009-05-06T22:02:08.692-04:00The Process of Managing ChangeChange is hard. I've had the opportunity to lead several programs that brought significant change into an organization, and these efforts have taught me a healthy respect for the challenges (and blessings) associated with organizational change. I've also learned from these experiences that there are some basic truths that should be remembered (I highlighted a collection of these principles in <a href="http://blog.softwarearchitecture.com/2009/04/10-principles-of-change-management.html">10 Principles of Change Management</a>) to set our change programs on solid footing. Building on that solid foundation, we can significantly improve our performance in establishing and sustaining meaningful organizational change by leveraging a structured methodology such as the work put forth by John Kotter in 1996 in <a href="http://www.amazon.com/gp/product/0875847471?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0875847471">Leading Change</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0875847471" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />. He followed up this work with <a href="http://www.amazon.com/gp/product/1578512549?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1578512549">The Heart of Change: Real-Life Stories of How People Change Their Organizations</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1578512549" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /> which brilliantly emphasizes the human/emotional aspect of the methodology. This book has become the corner stone of many successful change practices.<br /><br />I find the topic of Change Management more relevant than ever in today's corporate climate. It's been my recent experience that bigger leaps - bigger strategic bets - are required in organizational performance. Gradual and organic improvement is frequently not sufficient if we're to remain competitive. Indeed, a company's survival can depend on an ability to take big leaps in organizational capabilities or in bringing significant new products to market. This reminds me of the following quote shared recently by a very dear friend:<br /><blockquote>"King Saul thought Goliath was too big to fight, David thought he was too big to miss."<br /></blockquote>We need more Davids.<br /><br />The change management discipline doesn't apply only to large-scale organizational change. Even on average software development projects where one of the roles of the Architect (see <a href="http://www.blogger.com/blog.softwarearchitecture.com/2007/05/what-is-software-architect.html">What is A Software Architect?</a> and <a href="http://www.blogger.com/blog.softwarearchitecture.com/2007/06/most-important-compentencies-of.html">Most Important Competencies of the Software Architect</a>) is to lead the creation of an architecture and then champion that solution among the stakeholders, we're well served by taking these important concepts into account.<br /><br />The following offers a high-level overview of Kotter's change methodology. Experience suggests that trying to save time and effort by bypassing any of these eight steps will inevitably lead to even greater effort and frustration as change stalls and results become elusive. I highly recommend you master this material.<br /><br /><span style="font-weight: bold;">The Eight Stages of Successful Change<br /></span><ol><li>Increase urgency - People start telling each other, “let’s go, we need to change things!”</li><li>Build the guiding team - A group powerful enough to guide a big change is formed and they start to work together well. </li><li>Get the vision right - The guiding team develops the right vision and strategy for the change effort. </li><li>Communicate for buy-in - People begin to buy into the change, and this shows in their behavior </li><li>Empower action - More people feel able to act, and do act, on the vision </li><li>Create short-term wins - Momentum builds as people try to fulfill the vision, while fewer and fewer resist change. </li><li>Don’t let up - People make wave after wave of changes until the vision is fulfilled. </li><li>Make change stick - New and winning behavior continues despite the pull of tradition, turnover of change leaders, etc. </li></ol><span style="font-weight: bold;">Step 1 – Increase Urgency</span><br />Raise a feeling of urgency so that people say “let’s go,” making a change effort well positioned for launch. Go after the emotions with concrete and almost smell-able evidence, not just the abstractions so favored by the rational mind.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><ul><li>Showing others the need for change with an object that they can actually see, touch and feel.</li><li> Showing people valid and dramatic evidence from outside the organization that demonstrates that change is required.</li><li> Looking constantly for cheap and easy ways to reduce complacency.</li><li> Never underestimating how much complacency, fear and anger exists, even in good organizations.</li></ul><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><ul><li>Focusing exclusively on building a “rational” business case, getting top management approval, and racing ahead while mostly ignoring all the feelings that are blocking change.</li><li> Ignoring a lack of urgency and jumping immediately to creating a vision and strategy.</li><li> Believing that without a crisis or burning platform you can go nowhere.</li><li> Thinking that you can do little if you’re not the head person.</li></ul><span style="font-weight: bold;">Step 2 – Building the Guiding Team</span><br />Help form a group that has the capability – in membership and method of operating – to guide a very difficult change process.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><ul><li>Showing enthusiasm and commitment (or helping someone do so) to help draw the right people into the group.</li><li>Modeling the trust and teamwork needed in the group (or helping someone to do that).</li><li> Structuring meeting formats for the guiding team so as to minimize frustration and increase trust.</li><li>Putting your energy into step 1 (raising urgency) if you cannot take on the step 2 challenge and if the right people will not.</li></ul><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><ul><li>Guiding change with weak task forces, single individuals, complex governance structures, or fragmented top teams.</li><li> Not confronting the situation when momentum and entrenched power centers undermine the creation of the right group.</li><li> Trying to leave out or work around the head of the unit to be changed because he or she is “hopeless”.</li></ul><br /><span style="font-weight: bold;">Step 3 – Get the Vision Right</span><br />Create the right vision and strategies to guide action in all of the remaining stages of change.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Trying to see – literally – possible futures.</li><li> Visions that are so clear that they can be articulated in one minute or written up on one page.</li><li> Visions that are moving – such as a commitment to serving people.</li><li> Strategies that are bold enough to make bold visions a reality.</li><li> Paying careful attention to the strategic question of how quickly to introduce change.</li></ul><br /><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Assuming that linear or logical plans and budgets alone adequately guide behavior when you’re trying to leap into the future.</li><li> Overly analytic, financially based vision exercises.</li><li> Visions of slashing costs, which can be emotionally depressing and anxiety creating.</li><li> Giving people fifty-four logical reasons why they need to create strategies that are bolder than they have ever created before.</li></ul><br /><span style="font-weight: bold;">Step 4 – Communicate for Buy-In</span><br />Communicate change visions and strategies effectively so as to create both understanding and a gut-level buy-in.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Keeping communication simple and heartfelt, not complex and technocratic.</li><li> Doing your homework before communicating, especially to understand what people are feeling.</li><li> Speaking to anxieties, confusion, anger, and distrust.</li><li> Ridding communication channels of junk so that important messages can get through.</li><li> Using new technologies to help people see the vision (intranet, satellites, etc.).</li></ul><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Under communicating, which happens all the time.</li><li> Speaking as though you are only transferring information.</li><li> Accidentally fostering cynicism by not walking the talk.</li></ul><br /><span style="font-weight: bold;">Step 5 – Empower Action</span><br />Deal effectively with obstacles that block action, especially disempowering bosses, lack of information, the wrong performance measurement and reward systems, and lack of self-confidence.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Finding individuals with change experience who can bolster people’s self-confidence with we-won-you-can-too anecdotes.</li><li> Recognition and reward systems that inspire, promote optimism, and build self-confidence.</li><li> Feedback that can help people make better vision-related decisions.</li><li> “Retooling” disempowering managers by giving them new jobs that clearly show the need for change.</li></ul><br /><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Ignoring bosses who seriously disempower their subordinates.</li><li> Solving the boss problem by taking away their power (making them mad and scared) and giving it to their subordinates.</li><li> Trying to remove all the barriers at once.</li><li> Giving in to your own pessimism and fears.</li></ul><br /><span style="font-weight: bold;">Step 6 – Create Short-Term Wins</span><br />Produce sufficient short-term wins, sufficiently fast, to energize the change helpers, enlighten the pessimists, defuse the cynics, and build momentum for the effort.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Early wins that come fast.</li><li> Wins that are as visible as possible to as many people as possible.</li><li> Wins that penetrate emotional defenses by being unambiguous.</li><li> Wins that are meaningful to others – the more deeply meaningful the better.</li><li> Early wins that speak to powerful players whose support you need and do not yet have.</li><li> Wins that can be achieved cheaply and easily, even if they seem small compared with the grand vision.</li></ul><br /><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Launching fifty projects all at once.</li><li> Providing the first win too slowly.</li><li> Stretching the truth.</li></ul><br /><span style="font-weight: bold;">Step 7 – Don’t Let Up</span><br />Continue with wave after wave of change, not stopping until the vision is a reality, despite seemingly intractable problems.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Aggressively ridding yourself of work that wears you down – tasks that were relevant in the past but not now, tasks that can be delegated.</li><li> Looking constantly for ways to keep urgency up.</li><li> Using new situations opportunistically (as in “The Street”) to launch the next wave of change.</li><li> As always – show ‘em, show ‘em, show ‘em.</li></ul><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Developing a rigid four-year plan (be more opportunistic).</li><li> Convincing yourself that you’re done when you aren’t.</li><li> Convincing yourself that you can get the job done without confronting some of the more embedded bureaucratic and political behaviors.</li><li> Working so hard you physically and emotionally collapse (or sacrifice your off-the-job life).</li></ul><br /><span style="font-weight: bold;">Step 8 – Make Change Stick</span><br />Be sure the changes are embedded in the very culture of the enterprise so that the new way of operating will stick.<br /><br /><span style="font-weight: bold; font-style: italic;">What Works</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Not stopping at step 7 – it isn’t over until the changes have roots.</li><li> Using new employee orientation to compellingly show recruits what the organization really cares about.</li><li> Using the promotions process to place people who act according to the new norms into influential and visible positions.</li><li> Telling vivid stories over and over about the new organization, what it does, and why it succeeds.</li><li> Making absolutely sure you have the continuity of behavior and results that help a new culture grow.</li></ul><br /><span style="font-weight: bold; font-style: italic;">What Does Not Work</span><br /><span style="font-weight: bold; font-style: italic;"> </span><ul><li>Relying on a boss or a compensation scheme, or anything but culture, to hold a big change in place.</li><li> Trying to change culture as the first step in the transformation process.</li></ul>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com2tag:blogger.com,1999:blog-4123173409120259026.post-56654895375538387312009-04-27T10:16:00.005-04:002009-04-29T08:47:20.137-04:0010 Principles of Change ManagementStrategy and Business magazine recently posted a "Resilience Report" titled "<a href="http://www.strategy-business.com/resilience/rr00006?pg=all">10 Principles of Change Management</a>". As we've discussed (<a href="http://www.blogger.com/blog.softwarearchitecture.com/2007/05/what-is-software-architect.html">What is A Software Architect?</a>, <a href="http://www.blogger.com/blog.softwarearchitecture.com/2007/06/most-important-compentencies-of.html">Most Important Competencies of the Software Architect</a>, <a href="http://www.blogger.com/blog.softwarearchitecture.com/2007/06/governance-without-goodwill-is-dead.html">Governance Without Goodwill Is Dead</a>, <a href="http://www.blogger.com/blog.softwarearchitecture.com/2008/03/service-design-principles-and.html">Service Design Principles and Governance</a>), communication and leadership are critical skills for the Architect. These skills are really put to the test as part of initiatives with a large Change Management component - the sort of transformation programs the Architect is often asked to lead.<br /><br />Strategy and Business identifies the following 10 principles of Change Management. These principles articulate what you might consider to be fundamental truths and to varying degrees should inform nearly every change initiative. I'll follow up with a post about the process of managing change. A solid understanding of these principles and processes pays great dividends.<br /><br /><blockquote><span style="font-weight: bold;">1. Address the “human side” systematically.</span> Any significant transformation creates “people issues.” New leaders will be asked to step up, jobs will be changed, new skills and capabilities must be developed, and employees will be uncertain and resistant. Dealing with these issues on a reactive, case-by-case basis puts speed, morale, and results at risk. A formal approach for managing change — beginning with the leadership team and then engaging key stakeholders and leaders — should be developed early, and adapted often as change moves through the organization. This demands as much data collection and analysis, planning, and implementation discipline as does a redesign of strategy, systems, or processes. The change-management approach should be fully integrated into program design and decision making, both informing and enabling strategic direction. It should be based on a realistic assessment of the organization’s history, readiness, and capacity to change.<br /><br /><span style="font-weight: bold;">2. Start at the top.</span> Because change is inherently unsettling for people at all levels of an organization, when it is on the horizon, all eyes will turn to the CEO and the leadership team for strength, support, and direction. The leaders themselves must embrace the new approaches first, both to challenge and to motivate the rest of the institution. They must speak with one voice and model the desired behaviors. The executive team also needs to understand that, although its public face may be one of unity, it, too, is composed of individuals who are going through stressful times and need to be supported.<br /><br />Executive teams that work well together are best positioned for success. They are aligned and committed to the direction of change, understand the culture and behaviors the changes intend to introduce, and can model those changes themselves. At one large transportation company, the senior team rolled out an initiative to improve the efficiency and performance of its corporate and field staff before addressing change issues at the officer level. The initiative realized initial cost savings but stalled as employees began to question the leadership team’s vision and commitment. Only after the leadership team went through the process of aligning and committing to the change initiative was the work force able to deliver downstream results.<br /><br /><span style="font-weight: bold;">3. Involve every layer.</span> As transformation programs progress from defining strategy and setting targets to design and implementation, they affect different levels of the organization. Change efforts must include plans for identifying leaders throughout the company and pushing responsibility for design and implementation down, so that change “cascades” through the organization. At each layer of the organization, the leaders who are identified and trained must be aligned to the company’s vision, equipped to execute their specific mission, and motivated to make change happen.<br /><br />A major multiline insurer with consistently flat earnings decided to change performance and behavior in preparation for going public. The company followed this “cascading leadership” methodology, training and supporting teams at each stage. First, 10 officers set the strategy, vision, and targets. Next, more than 60 senior executives and managers designed the core of the change initiative. Then 500 leaders from the field drove implementation. The structure remained in place throughout the change program, which doubled the company’s earnings far ahead of schedule. This approach is also a superb way for a company to identify its next generation of leadership.<br /><br /><span style="font-weight: bold;">4. Make the formal case.</span> Individuals are inherently rational and will question to what extent change is needed, whether the company is headed in the right direction, and whether they want to commit personally to making change happen. They will look to the leadership for answers. The articulation of a formal case for change and the creation of a written vision statement are invaluable opportunities to create or compel leadership-team alignment.<br /><br />Three steps should be followed in developing the case: First, confront reality and articulate a convincing need for change. Second, demonstrate faith that the company has a viable future and the leadership to get there. Finally, provide a road map to guide behavior and decision making. Leaders must then customize this message for various internal audiences, describing the pending change in terms that matter to the individuals.<br /><br />A consumer packaged-goods company experiencing years of steadily declining earnings determined that it needed to significantly restructure its operations — instituting, among other things, a 30 percent work force reduction — to remain competitive. In a series of offsite meetings, the executive team built a brutally honest business case that downsizing was the only way to keep the business viable, and drew on the company’s proud heritage to craft a compelling vision to lead the company forward. By confronting reality and helping employees understand the necessity for change, leaders were able to motivate the organization to follow the new direction in the midst of the largest downsizing in the company’s history. Instead of being shell-shocked and demoralized, those who stayed felt a renewed resolve to help the enterprise advance.<br /><br /><span style="font-weight: bold;">5. Create ownership.</span> Leaders of large change programs must overperform during the transformation and be the zealots who create a critical mass among the work force in favor of change. This requires more than mere buy-in or passive agreement that the direction of change is acceptable. It demands ownership by leaders willing to accept responsibility for making change happen in all of the areas they influence or control. Ownership is often best created by involving people in identifying problems and crafting solutions. It is reinforced by incentives and rewards. These can be tangible (for example, financial compensation) or psychological (for example, camaraderie and a sense of shared destiny).<br /><br />At a large health-care organization that was moving to a shared-services model for administrative support, the first department to create detailed designs for the new organization was human resources. Its personnel worked with advisors in cross-functional teams for more than six months. But as the designs were being finalized, top departmental executives began to resist the move to implementation. While agreeing that the work was top-notch, the executives realized they hadn’t invested enough individual time in the design process to feel the ownership required to begin implementation. On the basis of their feedback, the process was modified to include a “deep dive.” The departmental executives worked with the design teams to learn more, and get further exposure to changes that would occur. This was the turning point; the transition then happened quickly. It also created a forum for top executives to work as a team, creating a sense of alignment and unity that the group hadn’t felt before.<br /><br /><span style="font-weight: bold;">6. Communicate the message.</span> Too often, change leaders make the mistake of believing that others understand the issues, feel the need to change, and see the new direction as clearly as they do. The best change programs reinforce core messages through regular, timely advice that is both inspirational and practicable. Communications flow in from the bottom and out from the top, and are targeted to provide employees the right information at the right time and to solicit their input and feedback. Often this will require overcommunication through multiple, redundant channels.<br /><br />In the late 1990s, the commissioner of the Internal Revenue Service, Charles O. Rossotti, had a vision: The IRS could treat taxpayers as customers and turn a feared bureaucracy into a world-class service organization. Getting more than 100,000 employees to think and act differently required more than just systems redesign and process change. IRS leadership designed and executed an ambitious communications program including daily voice mails from the commissioner and his top staff, training sessions, videotapes, newsletters, and town hall meetings that continued through the transformation. Timely, constant, practical communication was at the heart of the program, which brought the IRS’s customer ratings from the lowest in various surveys to its current ranking above the likes of McDonald’s and most airlines.<br /><br /><span style="font-weight: bold;">7. Assess the cultural landscape.</span> Successful change programs pick up speed and intensity as they cascade down, making it critically important that leaders understand and account for culture and behaviors at each level of the organization. Companies often make the mistake of assessing culture either too late or not at all. Thorough cultural diagnostics can assess organizational readiness to change, bring major problems to the surface, identify conflicts, and define factors that can recognize and influence sources of leadership and resistance. These diagnostics identify the core values, beliefs, behaviors, and perceptions that must be taken into account for successful change to occur. They serve as the common baseline for designing essential change elements, such as the new corporate vision, and building the infrastructure and programs needed to drive change.<br /><br /><span style="font-weight: bold;">8. Address culture explicitly.</span> Once the culture is understood, it should be addressed as thoroughly as any other area in a change program. Leaders should be explicit about the culture and underlying behaviors that will best support the new way of doing business, and find opportunities to model and reward those behaviors. This requires developing a baseline, defining an explicit end-state or desired culture, and devising detailed plans to make the transition.<br /><br />Company culture is an amalgam of shared history, explicit values and beliefs, and common attitudes and behaviors. Change programs can involve creating a culture (in new companies or those built through multiple acquisitions), combining cultures (in mergers or acquisitions of large companies), or reinforcing cultures (in, say, long-established consumer goods or manufacturing companies). Understanding that all companies have a cultural center — the locus of thought, activity, influence, or personal identification — is often an effective way to jump-start culture change.<br /><br />A consumer goods company with a suite of premium brands determined that business realities demanded a greater focus on profitability and bottom-line accountability. In addition to redesigning metrics and incentives, it developed a plan to systematically change the company’s culture, beginning with marketing, the company’s historical center. It brought the marketing staff into the process early to create enthusiasts for the new philosophy who adapted marketing campaigns, spending plans, and incentive programs to be more accountable. Seeing these culture leaders grab onto the new program, the rest of the company quickly fell in line.<br /><br /><span style="font-weight: bold;">9. Prepare for the unexpected.</span> No change program goes completely according to plan. People react in unexpected ways; areas of anticipated resistance fall away; and the external environment shifts. Effectively managing change requires continual reassessment of its impact and the organization’s willingness and ability to adopt the next wave of transformation. Fed by real data from the field and supported by information and solid decision-making processes, change leaders can then make the adjustments necessary to maintain momentum and drive results.<br /><br />A leading U.S. health-care company was facing competitive and financial pressures from its inability to react to changes in the marketplace. A diagnosis revealed shortcomings in its organizational structure and governance, and the company decided to implement a new operating model. In the midst of detailed design, a new CEO and leadership team took over. The new team was initially skeptical, but was ultimately convinced that a solid case for change, grounded in facts and supported by the organization at large, existed. Some adjustments were made to the speed and sequence of implementation, but the fundamentals of the new operating model remained unchanged.<br /><br /><span style="font-weight: bold;">10. Speak to the individual.</span> Change is both an institutional journey and a very personal one. People spend many hours each week at work; many think of their colleagues as a second family. Individuals (or teams of individuals) need to know how their work will change, what is expected of them during and after the change program, how they will be measured, and what success or failure will mean for them and those around them. Team leaders should be as honest and explicit as possible. People will react to what they see and hear around them, and need to be involved in the change process. Highly visible rewards, such as promotion, recognition, and bonuses, should be provided as dramatic reinforcement for embracing change. Sanction or removal of people standing in the way of change will reinforce the institution’s commitment.<br /><br />Most leaders contemplating change know that people matter. It is all too tempting, however, to dwell on the plans and processes, which don’t talk back and don’t respond emotionally, rather than face up to the more difficult and more critical human issues. But mastering the “soft” side of change management needn’t be a mystery."</blockquote><br /><br />Watch for the follow up on the process of change and look for every opportunity to learn more about Change Management principles. Great Architects are distinguished by practical skills in this area.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com1tag:blogger.com,1999:blog-4123173409120259026.post-57295636942625836602009-01-05T15:07:00.005-05:002009-01-05T15:49:34.456-05:00Hottest Posts in 20082008 was a good year for the practice of software architecture. Good progress is being made throughout the industry in recognition of Architecture as a distinct discipline, and the maturity of the discipline was advanced by the excellent writings of a host of passionate practitioners. Looking back at the year on SoftwareArchitecture.com, I found it interesting to note the most popular posts of 2008. People are clearly interested in understanding the profession and reinforcing their practice. Let's keep it up!<br /><br />The top 10 most popular posts of 2008:<br /><ol><li><a href="http://blog.softwarearchitecture.com/2007/05/what-is-software-architecture.html">What Is Software Architecture?</a></li><li><a href="http://blog.softwarearchitecture.com/2007/07/good-architecture-descriptions-are_03.html">Good Architecture Descriptions are Explosive</a></li><li><a href="http://blog.softwarearchitecture.com/2007/05/service-design-principles-contract.html">Service Design Principles (the Contract Story Continues)</a></li><li><a href="http://blog.softwarearchitecture.com/2007/06/most-important-compentencies-of.html">Most Important Competencies of the Software Architect</a></li><li><a href="http://blog.softwarearchitecture.com/2007/05/what-is-software-architect.html">What is a Software Architect?</a></li><li><a href="http://blog.softwarearchitecture.com/2007/05/architect-is-accountable.html">The Architect is Accountable!</a></li><li><a href="http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html">Progressive Refinement of Estimates (aka The Transmission Repair)</a></li><li><a href="http://blog.softwarearchitecture.com/2007/07/proactive-architect.html">The Proactive Architect</a></li><li><a href="http://blog.softwarearchitecture.com/2007/06/governance-without-goodwill-is-dead.html">Governance Without Goodwill is Dead</a></li><li><a href="http://blog.softwarearchitecture.com/2007/06/making-of-governance-anti-pattern.html">The Making of a Governance Anti-Pattern?</a></li></ol>I hope you have found something thought-provoking. As always, I love hearing from you.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-58682935545155535152008-08-14T23:52:00.007-04:002008-08-31T09:56:49.793-04:00Organize Around the Architecture (#1)In a post titled “<a href="http://blog.objectmentor.com/articles/2008/06/29/contracts-and-integration-tests-for-component-interfaces">Contracts and Integration Tests for Component Interfaces</a>” at Object Mentor, Dean Wampler discussed agile development and the communications between teams. As usual, Dean makes a number of good observations, and I’d like to pick up and expound on a couple of his thoughts.<br /><br />For many years I led teams that had fully adopted agile practices. We had refined our development approach (and continually did so) to be extremely productive. Our responsibilities were almost exclusively for common services that were used at the enterprise level, which included everything from Credit Card Processing and Campaign Management to Subscriber Identity Verification. In those days, the overwhelming majority of the teams we worked with were still fully rooted in traditional/waterfall methods, and just like the teams Dean described, these teams were very reliant on BDUF.<br /><br />Working with those teams, we were very quickly able to get ourselves into a position where we stayed barely ahead of them. We performed independent analysis in the business domain and consistently developed the services that would ultimately be needed. Of course, we always made sure not to get too far out in front where we might run too high a risk of disconnecting from or misunderstanding the true business objectives, needs, and priorities. Operating in this mode, there was at least a theoretical danger of building things we didn’t need, but in practice, over more than five years, that didn’t happen a single time. By maintaining close relationships with the “customers” (which included both the true business customer and the other development teams that would consume the services) and constantly communicating about their needs, we consistently blazed the trail just in front of where they wanted to go and made it possible for them to keep marching unencumbered towards their goals.<br /><br />From a technology standpoint, we did something pretty similar to what Dean suggests. Though they’re absolutely a prerequisite, static definitions of contracts are not sufficient for reliable communications and assurance of unified expectations (see also <a href="http://blog.softwarearchitecture.com/2007/05/contracts-are-thing.html">Contracts are the Thing</a> and <a href="http://blog.softwarearchitecture.com/2007/05/service-design-principles-contract.html">Service Design Principles (The Contract Story Continues)</a>). In our case, we delivered in four steps and provided the following in rapid succession to each team: 1) static definition of the contract, 2) client-side mock, 3) server-side mock, and 4) operational service. Sometimes this would all happen within just a sprint or two, and it always allowed the teams to actively participate in the evolving understanding of the dependency and how it could be incorporated into their design and delivery.<br /><br />By the way, in those days (for calibrated reasons) we were exposing these capabilities as J2EE services, so part of our practice was to deliver a simple client library that encapsulated all the details about communicating with the service. This design was something we first delivered in 2001. It was in this thin library that the client-side mock was implemented. It allowed developers on those teams to start calling the service very early on, when they were ready, even if we were not. That mock remained available in the client library for future testing and development purposes and was typically activated by qualifying the service endpoint. With barely sufficient richness in the communication with the mock (e.g., the type of responses available), the dependent team was able to recognize potential integration pitfalls very early. This led to much greater accuracy, reliability, and validation of the interfaces.<br /><br />You’ll notice that this approach heavily emphasizes the principle of “Organizing Around the Architecture,” which promotes segmenting a project or program into manageable sub-parts (and corresponding sub-teams) with clear and defined roles and responsibilities that in aggregate accomplish the goals of the overall initiative. Specifically, the dependency between each team should be in alignment with the architecture and in some fashion documented by the “contract” for the services being provided by those teams. For large-scale development programs, I consider this sort of organization to be essential. In fact, I think we all understand the importance of subdividing any large effort into manageable structures (and accountabilities).<br /><br />Which brings me to my last point. Dean mentions the use of “virtual feature teams.” While that's a common approach and is often used successfully (especially for small to medium efforts where scope and scale are more easily managed), there’s an inherent risk in any approach that doesn’t respect the natural correlation between the structure of the organization (the people) and the structure of the architecture (the product). It’s been proven time and time again that the architecture of a product will tend to follow the organization of the people designing and delivering that product. I’ll talk more about this in a future post, but for now, as we think about the relationships between teams, how they’re structured, and how they communicate, let’s be sure to take the “Organize Around the Architecture” principle into account.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com1tag:blogger.com,1999:blog-4123173409120259026.post-6918568616700955002008-04-17T22:57:00.001-04:002008-04-17T23:33:15.257-04:00My First Computer or TwoWhy I'd want to share this is beyond me. Why date myself?!? Inspired by a post today from Todd Bliske (<a href="http://www.biske.com/blog/?p=396">My First Computer(s)</a>), I thought I'd follow suit and reminisce about my early computers. A few fun memories.<br /><br />While there were a few steps along the way, I really think of two worth mentioning. As a teenager, there were many hours of coding pleasure at the keyboard of a Tandy TRS-80 Model I. The one I had was quite similar to this one described very nicely by the good folks over at "<a href="http://www.vintage-computer.com/trs80mod1.shtml">Vintage Computer</a>".<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-8NV7-3C7SkTrxy645y94KllP8ANJ23WgyuauYyBnxYSE_7ImjU_9cgcKCJfGEtqyKFg8SsdwJy_5_g4i4YKZRItWzZs8F5EMuNttnqil4cVyZRzogA4XLryfc_BG4bEduebtg0nkdRk/s1600-h/trs80mod1system.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-8NV7-3C7SkTrxy645y94KllP8ANJ23WgyuauYyBnxYSE_7ImjU_9cgcKCJfGEtqyKFg8SsdwJy_5_g4i4YKZRItWzZs8F5EMuNttnqil4cVyZRzogA4XLryfc_BG4bEduebtg0nkdRk/s320/trs80mod1system.jpg" alt="" id="BLOGGER_PHOTO_ID_5190377515112655442" border="0" /></a><br />I hate to think how much time I spent hacking at Basic programs on that thing. See the device under the monitor? The one that's about the size of a dvd player or something like that? That was an expansion interface that enabled the connection of a floppy disk. Before adding that brilliant upgrade, all the persistent storage was handled via cassette!<br /><br />Fast forward a few years to good times in the U.S. Air Force, and things got a little bigger - but marginally more capable. For several years, I had the distinct pleasure of developing on a TI-980B. Check out this awesome front panel.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAsyJXmzktoHFN-vxipPiRghLtrzt88D_AwrUgT4Oj3fUPN2za2CnV14_cRF5k8ythKolwa0HI7M_FCB4e1dFxLlQVPmZaYdbMtOmVAsdDoigj_Iyb6Fxm8Y0c30sXH17ljVNTXxxX82Y/s1600-h/storage.ti980.panel.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAsyJXmzktoHFN-vxipPiRghLtrzt88D_AwrUgT4Oj3fUPN2za2CnV14_cRF5k8ythKolwa0HI7M_FCB4e1dFxLlQVPmZaYdbMtOmVAsdDoigj_Iyb6Fxm8Y0c30sXH17ljVNTXxxX82Y/s320/storage.ti980.panel.jpg" alt="" id="BLOGGER_PHOTO_ID_5190368517156170290" border="0" /></a><br />This was a beast, but what a lot of fun. Featuring a switch-initiated ROM bootstrap loader, one would walk up to the machine and execute a flurry of load instructions via those toggle switches, and voila! The beast stirs to life, completing its load from good ole 9-track tape. Armed with a 4 mhz clock and a whopping 16k of dynamic MOS/LSI semiconductor memory (spanning two full-size circuit boards), almost anything was possible. One of the things I remember most was a single DMA port with 6 full circuit boards for I/O expansion. As I recall, there were literally 26 cards in the disk controller. Oh, and that disk. You know the one. Remember these?<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjB7ykyMufXRvtELXm6hFFIcwKUSp5y3tp1sPrmQyb6oNwG6F7Bp2iRQd3__v2MB3bFiNtQesMGVS63wiVgeqQ3TLHtpspttb4PftdNYcsp_dCQnTmqdIAXtwF99WYUp2TWj3yK1KHx7Ls/s1600-h/ibmdisk.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjB7ykyMufXRvtELXm6hFFIcwKUSp5y3tp1sPrmQyb6oNwG6F7Bp2iRQd3__v2MB3bFiNtQesMGVS63wiVgeqQ3TLHtpspttb4PftdNYcsp_dCQnTmqdIAXtwF99WYUp2TWj3yK1KHx7Ls/s320/ibmdisk.jpg" alt="" id="BLOGGER_PHOTO_ID_5190375041211492930" border="0" /></a>If memory serves, that whirlpool-sized "mass" storage device provided 100mb of storage and involved a pack with 10 platters and 406 cylinders. It looked something like this one at Wikipedia: <a href="http://en.wikipedia.org/wiki/Image:DysanRemovableDiskPack.agr.jpg">Removable Disk Pack</a>. In those days (relatively speaking, it's really not that long ago), head crashes were a notable risk. And what a mess that was. Metal shavings everywhere! It wasn't pretty.<br /><br />Not too long after that, things got a little simpler, and I remember going through a <a href="http://en.wikipedia.org/wiki/Commodore_64">Commodore 64</a> and a <a href="http://en.wikipedia.org/wiki/Commodore_128">Commodore 128</a> before landing on a machine that was a lot of fun for a number of years. The Amiga was a system truly ahead of its time. Both my kids learned how to use a computer (and fling floppies all over the room) on a proud <a href="http://en.wikipedia.org/wiki/Amiga_1000">Amiga 1000</a>. It brings a smile to my face even now to think about my 2 year old selecting and inserting floppies to play his "First Shapes from First Byte" game. I can even still hear the robot voice... "First Shapes from First Byte."<br /><br />Anyone remember the game "Tower Toppler?" Fun times.<br /><br />How about you? What did those early days look like for you?Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com1tag:blogger.com,1999:blog-4123173409120259026.post-51430524115178863162008-03-29T09:41:00.006-04:002008-03-30T22:30:20.988-04:00Who Has the Power?Today's post over at The Heart of Innovation is titled "<a href="http://www.ideachampions.com/weblogs/archives/2008/03/_the_root_of_th.shtml">Managers Need to Become Innovation Coaches</a>" and offers guidance that good architects will do well to apply. While the article (and the short extract below) focuses on the role of the "manager", these principles are more aptly described as characteristics of good leadership in nearly any role - especially that of the architect.<br /><blockquote>Most managers, unfortunately, perceive new ideas as problems. [Instead] they foist their ideas on others and can't figure out why things aren't happening faster.<br /><br />That's not how change happens. If people are only acting out somebody else's ideas, it's only a matter of time before they feel discounted, disempowered and... well...just plain dissed. People are more than hired hands; they are hired minds and hearts, as well.<br /><br />If you want to empower people, honor their ideas. Give them room to challenge the status quo. Give them room to move -- and, by extension, move mountains.<br /><br />Who has the power in an organization? The people who are allowed to think for themselves and then act on their ideas! Who doesn't have power? The people who have to continually check-in with others.<br /></blockquote>The idea of empowerment is essential. No matter how smart and capable the architect, the true "brilliance" of a team or an organization lies in the collective mind (<a href="http://blog.softwarearchitecture.com/2007/09/leadership-secret-sauce.html">Leadership - The Secret Sauce</a>). This brilliance can be tapped only through legitimate empowerment, and that means we all should ask ourselves "who has the power" in an organization, on a team, or on a project. Good things happen when the architect provides leadership - and the team provides power.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-87775085475972784812008-03-25T03:23:00.001-04:002008-03-25T04:08:44.435-04:00Progressive Refinement of Estimates (aka The Transmission Repair)<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDqnaqEggerEL51QYeF_cigC7MvYG53Qi2w1JJisKRyztD7Qnxt_O11N0cYT-pVGyRkZYfFOnU-HBYad7qqGdlSy93gIU3gQtZJkL_YGYCAySsYT68-0kPc6KmZd0YLt8AoAEInZPfrv0/s1600-h/mytranny.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDqnaqEggerEL51QYeF_cigC7MvYG53Qi2w1JJisKRyztD7Qnxt_O11N0cYT-pVGyRkZYfFOnU-HBYad7qqGdlSy93gIU3gQtZJkL_YGYCAySsYT68-0kPc6KmZd0YLt8AoAEInZPfrv0/s320/mytranny.jpg" alt="" id="BLOGGER_PHOTO_ID_5180605552341229026" border="0" /></a>Not too long ago, I had to have the transmission in my vehicle rebuilt. While car troubles are never a pleasant experience, this one created an experience that I think we can apply to many of our software development initiatives. You see, when I walked in to my friendly neighborhood repair shop, I was a bit anxious and really "needed" to know right there on the spot what was wrong with my car and how much it would cost to get it fixed. Oh, and when I would get it back. As you can imagine, it didn't quite play out that way. You see, the transmission guy, being the experienced professional that he is, knew he wasn't in a position to reliably answer those questions - yet. But he also knew how to work with me through a series of activities that would progressively refine our collective awareness of the answers - and ultimately be mutually beneficial. Here's how the story played out.<br /><br /><span style="font-weight: bold;">The Transmission Repair Story<br /><br /></span><span style="font-weight: bold; font-style: italic;">Day 1 - 10AM - The Contact</span><br />Transmission's been slipping for a few days, so I head up to see "Ray" the transmission doctor. Walked in the front door and was greeted cheerfully. Explained the symptoms to Ray and asked the obvious questions: 1) What's wrong?, 2) How much will it cost?, and 3) When will it be done? Of course, Ray's been through this with hundreds of customers, and he knows he's not in a position to answer those "ever-so-important" questions. But he knows just what to do, so he explains how the process will work - and how it will meet my needs and get my car back on the road in a jiffy. Ray tells me the next step is to allow him to do a road inspection. He'll drive the car and observe the behavior himself. He'll even do some investigation with the car up on the rack in his shop. He says once he's completed that assessment, he'll give me a call and let me know where we stand.<br /><br />At my prompting, he lets me know that the trouble could be something simple like contaminated fluid or mechanical adjustments, or it could be a more complicated problem requiring more extensive repair. On the lower end, Ray says it might cost as little as a few hundred dollars. He cautiously points out, however, that major repairs can be well over two thousand.<br /><br />I anxiously awaited his call.<br /><br /><span style="font-weight: bold; font-style: italic;">Day 1 - 3PM</span><span style="font-style: italic;"><span style="font-weight: bold;"> - The Engagement</span> </span><br />At about 3 that afternoon, Ray calls to give me the update. It's a little bit of bad news, as the early indication is that there is indeed damage in the transmission, and it will need to be repaired. Ray gives me a bit of confidence by explaining what he observed and what that might mean. He is able to correlate his observations to many past experiences and makes me feel good that I'm on a path that many have successfully gone down before. According to Ray, repairs are going to cost between $1100 and $1800, and the correlation to previous work makes me feel confident with this range.<br /><br />Ray goes on to explain that the next step is for him to get the transmission off the vehicle and onto the bench so he can open it up and look inside. Once on the inside, he'll be able to determine more clearly which parts need to be replaced and what work needs to be done. With that new information, he'll be in a position to give me a more reliable estimate.<br /><br />Ray says that it's a lot of work to pull the transmission out to take it apart and do the detailed diagnosis. For this work, there will be a charge of $600. If I choose to follow through with the repair, that charge is simply part of the $1100-$1800 estimate. However, after Ray does the diagnosis and comes up with the updated price, if I choose not to proceed with the work (because, for example, cousin Charlie says he'll do it for a couple six-packs), then I'll owe Ray the $600 for his work.<br /><br />While I'm not too crazy about this idea (it limits my options and makes me commit), I really can't argue against it. It only seems fair. I give the go ahead, and Ray promises to call me with an update within 48 hours.<br /><br /><span style="font-weight: bold; font-style: italic;">Day 3 - 11AM - The Commitment</span><br />A little less than two days later, Ray has completed the detailed assessment and calls with the news. Along with several other parts, Ray will need to replace the governor pressure solenoid, the servo piston, and the boost valve. I have no idea what any of those things do, but Ray offers to explain in as much detail as I'd like. He wants me to be comfortable and confident in the estimate. With these new parts, his labor, and a couple pieces he has to send out to the machine shop for reconditioning, the revised total estimate is $1700 - $1850 and I can have the car back within 3 days. I give Ray the authorization, and he gets to work.<br /><br /><span style="font-weight: bold; font-style: italic;">Day 4 - 2PM - The Change Request</span><br />Ray called to tell me he was making good progress on the transmission. It'll be ready for me to pick up tomorrow. That's good news!<br /><br />He also wanted to let me know about something he'd learned during the repair. Once he had the transmission all apart and cleaned, he noticed that the #4 gear had some pitting on the inner surface of the teeth. He explains that this isn't something that will cause trouble any time soon, but he wanted to present me with the option of taking care of it now while everything is already out on the bench, potentially avoiding a second, more expensive repair at a later date. The part would cost an extra $75 plus $50 for labor. If I opt for the additional work, my revised total grows to $1825 - $1975.<br /><br />After careful consideration, I decline the additional repair.<br /><br /><span style="font-style: italic; font-weight: bold;">Day 5 - 4PM - The Delivery</span><br />The car's ready. The total came to $1797, and I can pick it up anytime before 6.<br /><br /><span style="font-weight: bold;">The Lesson</span><br /><br />Before getting into the lessons learned in this experience, it might be a good idea to review Ray's process:<br /><br />1. The Contact - Customer explains the trouble. Ray agrees to spend a couple hours investigating. This investigation will result in an understanding of scope and constraints and provide both Ray and the customer the information they need to make decisions about how to move forward.<br /><br />2. The Engagement - Ray explains the results of the initial investigation and provides options. Customer agrees to a minimal investment to conduct the more in-depth assessment that will include removing and disassembling the transmission in order to generate a detailed work plan.<br /><br />3. The Commitment - Ray explains what he learned during the in-depth assessment and provides a reliable estimate for the repair along with details about when he can deliver. Customer agrees to the terms of Ray's plan.<br /><br />4. The Delivery - Ray completes the work and delivers on-time and on-budget. Customer is satisfied.<br /><br />It seems Ray has this process nailed down. He avoided making a commitment (or asking me to) before there was a reasonable level of understanding of the work that would be required, and he walked me through each step of the process right up to the final successful delivery. While there were steps in that process that I really wish could have worked differently, I knew I had to be reasonable. For example, in that first interaction ("The Contact"), it wouldn't have done a bit of good for me to pitch a fit and throw a temper tantrum in an attempt to get Ray to cave and tell me exactly what was wrong and what it would cost. Likewise, Ray knew it would be just as unreasonable to avoid giving me a cost estimate as early in the process as possible. If he couldn't (or wouldn't) give me an estimate (even a wide range) at "The Engagement" stage, I surely wouldn't enter into the arrangement, and I'd have to take my business elsewhere. Throughout the process, we agreed to collaboratively work through a series of well-specified milestones. Each step resulted in the addition of new information and yielded an increasing ability for each of us to understand what we were getting ourselves into - and what we could each expect to receive in return.<br /><br /><span style="font-weight: bold;">Applying the Lesson</span><br /><br />Let's be encouraged to apply the same reasonable and responsible sort of process to software delivery. Our customers can understand why precise estimates are not possible when there is little or no data, and we can understand that it is absolutely essential that we provide estimates that can be used for coarse-grained business planning as early as possible. All too often, this devolves into an emotional tug-of-war where nobody wins.<br /><br />We all come out ahead when we design processes like Ray's and work collaboratively to step through a progression of estimates that become more and more reliable as a project unfolds and new data becomes available.<br /><br />One last thing. You may be interested in comparing Ray's process to the Rational Unified Process, in which you'll immediately be able to draw simple parallels:<br /><br />"The Engagement" = The Life Cycle Objective Milestone (LCO)<br />"The Commitment" = The Life Cycle Architecture Milestone (LCA)<br />"The Delivery" = The Initial Operational Capability Milestone (IOC)<br /><br />These milestones give us a good framework for the reasonable and responsible collaboration that makes Ray's process a success.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com6tag:blogger.com,1999:blog-4123173409120259026.post-48701060350535343002008-03-19T07:44:00.009-04:002008-03-22T10:17:54.562-04:00Service Design Principles And Governance<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwd813pPISgx7DGO81lIonpGVwbN_OShuIJtiwqxOgtJmvE4pb8U39Xz0ATnwJ3PW-D6T2yUsktoGHwuR9mX1FgXandAErfLS-_EmAOn3eI4Uq3Ig7438g2QSci5AT9Gv2FCQYIFuKXI0/s1600-h/ServiceDesignPrinciplesFunnel.jpg"><img style="margin: 0pt 10px 10px 0pt; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwd813pPISgx7DGO81lIonpGVwbN_OShuIJtiwqxOgtJmvE4pb8U39Xz0ATnwJ3PW-D6T2yUsktoGHwuR9mX1FgXandAErfLS-_EmAOn3eI4Uq3Ig7438g2QSci5AT9Gv2FCQYIFuKXI0/s320/ServiceDesignPrinciplesFunnel.jpg" alt="" id="BLOGGER_PHOTO_ID_5179442647552084402" border="0" /></a><br />A good architecture governance capability has at it's heart a focus on developing people and encouraging excellence (see <a href="http://blog.softwarearchitecture.com/2007/06/governance-without-goodwill-is-dead.html">Governance Without Goodwill is Dead</a>). I like to think of it in terms of a leadership capability of the sort alluded to in this Dwight Eisenhower quote:<br /><blockquote>"Leadership is the art of getting someone else to do something you want done because he wants to do it."<br /></blockquote>With that backdrop, and as part of an emerging governance program, I've recently had the need to introduce or reinforce a set of service design principles to a large audience and begin developing a shared and actionable understanding of these practices. The goal is to increase community awareness and support for good design and to further develop good design skills throughout the community.<br /><br />A good source for this material is Thomas Erl's <a href="http://www.amazon.com/gp/product/0132344823?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0132344823">SOA Principles of Service Design</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0132344823" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />, and many in the community have been encouraged to buy the book. In fact, we've given away a couple dozen of them. To further jump-start the process, it has been helpful to create a high-level representation of these principles that can be used in introductory sessions and training. Doing so has begun to instill a common language and frame of reference.<br /><br />You can download a copy of the <a href="http://softwarearchitecture.s3.amazonaws.com/ServiceDesignPrinciples.pdf">design principles document</a>. It's a bit large due to the graphics. Following is a quick preview.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD1TBZxze6dBo-WszarVRY83kr2XmsPE7R6tkHfw7Kz8DklftSL4k-f6CusmQkIGHnTMzxeAMGYcWKGIMguheX68vkBp_UZ0R-06osaG62ufVHkXXWGGCBppU385nuAcvD5p7l9eA3Ag/s1600-h/ServiceDesignPrinciples1.jpg"><img style="margin: 0pt 10px 10px 0pt; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrD1TBZxze6dBo-WszarVRY83kr2XmsPE7R6tkHfw7Kz8DklftSL4k-f6CusmQkIGHnTMzxeAMGYcWKGIMguheX68vkBp_UZ0R-06osaG62ufVHkXXWGGCBppU385nuAcvD5p7l9eA3Ag/s320/ServiceDesignPrinciples1.jpg" alt="" id="BLOGGER_PHOTO_ID_5179441453551176082" border="0" /></a><br /><br /><span style="font-weight: bold;">Standardized Contract</span> - Implement a standardized contract<br /><blockquote> Services within the same service inventory are in compliance with the same contract design standards<br /></blockquote><span style="font-weight: bold;">Loose Coupling</span> - Minimize dependencies<br /><blockquote> Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment<br /></blockquote><span style="font-weight: bold;">Abstraction</span> - Minimize the availability of meta information<br /><blockquote> Service contracts only contain essential information and information about services is limited to what is published in service contracts<br /></blockquote><span style="font-weight: bold;">Reusability</span> - Implement generic and reusable logic and contract<br /><blockquote> Services contain and express agnostic logic and can be positioned as reusable enterprise resources<br /></blockquote><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDk-jI-F_srQPV8gIBtcT_-2uWVRt3SkQ_IPqEsMOEX-6f0Po_QnqTV-bo-Bb0DAVZsU6Iu7wIqHJ878tmsFBfMUkZYDe3wQ3TsFtq8ICXpg41oUczBsxNVikti3WnbXTFmADBoPuNEpc/s1600-h/ServiceDesignPrinciples2.jpg"><img style="margin: 0pt 10px 10px 0pt; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDk-jI-F_srQPV8gIBtcT_-2uWVRt3SkQ_IPqEsMOEX-6f0Po_QnqTV-bo-Bb0DAVZsU6Iu7wIqHJ878tmsFBfMUkZYDe3wQ3TsFtq8ICXpg41oUczBsxNVikti3WnbXTFmADBoPuNEpc/s320/ServiceDesignPrinciples2.jpg" alt="" id="BLOGGER_PHOTO_ID_5179442411328883106" border="0" /></a><br /><span style="font-weight: bold;">Autonomy</span> - Implement independent functional boundary and runtime environment<br /><blockquote> Services exercise a high level of control over their underlying runtime execution environment<br /></blockquote><span style="font-weight: bold;">Composability</span> - Maximize composability<br /><blockquote> Services are effective composition participants, regardless of the size and complexity of the composition<br /></blockquote><span style="font-weight: bold;">Statelessness</span> - Implement adaptive and state management-free logic<br /><blockquote> Services minimize resource consumption by deferring the management of state information when necessary<br /></blockquote><span style="font-weight: bold;">Discoverability</span> - Implement communicative meta information<br /><blockquote> Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted</blockquote><br />Hope you find this useful. To learn more about these principles, be sure to get a copy of <a href="http://www.amazon.com/gp/product/0132344823?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0132344823">SOA Principles of Service Design</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0132344823" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /> and download a copy of the <a href="http://softwarearchitecture.s3.amazonaws.com/ServiceDesignPrinciples.pdf">design principles document</a>.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com3tag:blogger.com,1999:blog-4123173409120259026.post-48487912678760604052008-02-24T06:42:00.002-05:002008-02-24T09:22:03.148-05:00Right Ways of Working with the Left Brain"<a href="http://www.ideachampions.com/heartofinnovation/">The Heart of Innovation</a>" is the blog for <a href="http://www.ideachampions.com/index.shtml">Idea Champions</a>, the highly-respected consulting and training company specializing in creativity, innovation, team building, and leadership. A recent post titled "<a href="http://www.ideachampions.com/weblogs/archives/2008/02/right_ways_of_w.shtml">Right Ways of Working with the Left Brain</a>" offered some valuable suggestions for helping to lead left-brained people (like most of us) through creative activities. The article opens with:<br /><blockquote>"If your job requires you to lead meetings, brainstorming sessions, or problem solving gatherings of any kind, chances are good that most of the people you come in contact with are left-brain dominant: analytical, logical, linear folks with a passion for results and a gnawing fear that the meeting you are about to lead will end with a rousing chorus of kumbaya."</blockquote>I can relate.<br /><br />The 10 practices are listed here, but check out the article for details - and fine-tune your ability to provide leadership throughout the creative process. As discussed in <a href="http://blog.softwarearchitecture.com/2007/05/architect-as-advocate-of-business.html">Architect as Advocate of the Business</a> and <a href="http://blog.softwarearchitecture.com/2007/07/proactive-architect.html">The Proactive Architect</a>, these sorts of leadership skills help distinguish world-class architects.<br /><br /><span style="font-weight: bold;">Ten Tips for Leading Creative Activities:</span><br /><br /><strong>1. Diffuse the fear of ambiguity by continually clarifying the process<br /></strong><strong>2. Get people talking about AHAS! they've had in their own lives<br /></strong><strong>3. Identify (and transform) limiting assumptions<br /></strong><strong>4. Encourage idea fluency<br /></strong><strong> 5. Invite humor<br /></strong><strong>6. Do the right brain/ left brain two-step<br /></strong><strong>7. Periodically mention that chaos precedes creative breakthroughs</strong><br /><strong>8. Establish criteria for evaluation<br /></strong><strong>9. Be a referee when you have to<br /></strong><strong>10. Consult with the tough people on the breaks<br /></strong><br />Check out the full article here: <a href="http://www.ideachampions.com/weblogs/archives/2008/02/right_ways_of_w.shtml">Right Ways of Working with the Left Brain</a>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-59516192475053264282008-02-16T15:44:00.006-05:002008-02-16T16:20:52.949-05:00Think Bigger!Jeff had a very nice post recently about the all too common problem of Engineers becoming inappropriately fixated with things that are important to Engineers (as opposed to things important to the business and to the users). He points out that he gets "frustrated with the depth of our obsession" over things that are very important and necessary (such as unit tests that are absolutely foundational to professional development) but are sometimes allowed to overshadow the things that are MOST important. Jeff remarks, "<a href="http://www.codinghorror.com/blog/archives/001059.html">the ultimate unit test</a> is whether or not users want to use your application" and continues with, "I want to run up to my fellow programmers and physically shake them: think bigger!" And I want to shout, Amen!<br /><br />But then something odd happens. In response to his post, developers (apparently suffering from precisely the ailment Jeff just described) completely validate his entire premise (that sometimes we fail to see the forest for the trees). One after another weighs in with a comment such as, "unit testing has nothing to do with usability" (boldly paraphrasing).<br /><br />Finally, <a href="http://blog.primordial.com/">Kyle</a> pipes up with the voice of reason:<br /><blockquote>"While [it's true] Engineers should be concerned with whether they are building the product right (verification), their overriding concern should be whether they are building the right product (validation).<br /><br />It is important for engineers to get their head above the water and see the bigger picture sometimes."</blockquote>Kudos to Jeff, Kyle, and all of you who remind us to "think bigger", "get [our] head above water", and remember that our real mission is (as Jeff concludes):<br /><blockquote>"The ultimate unit test is whether or not users want to use your application. All the other tests you write are totally irrelevant until you can get that one to pass."</blockquote>Building the product right is very important. Building the right product is essential!Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com2tag:blogger.com,1999:blog-4123173409120259026.post-20134663620717721732007-12-30T17:45:00.000-05:002007-12-30T17:49:54.528-05:00The Process For Saying "No"<b></b>Consider the following hypothetical scenario. I know it's a stretch - this never happens to any of us - but let's use our imagination...<br /><br /><blockquote>We've been through it time and time again. The requests keep coming, and the organization keeps taking them in. Our capacity (considered individually, as a team, or as an organization) to satisfy the requests has long been over-committed, and the team is staying afloat only by extraordinary effort and sheer determination. But now the band is winding too tightly, and the cracks in the armour have begun to show - and stuff's starting to fall through those cracks.</blockquote><br />As I said, this sort of thing rarely happens to any of us, but let's talk it over and be prepared just in case. As with any risky proposition, it's good to have a strategy in place. We need to develop a response pattern that will increase the likelihood of success... just in case.<br /><br />Considering the scenario at hand, we could pursue a few different options. For example, we could continue to advance the "just say yes" mantra, or we could go hard core and beat the "just say no" drum. It seems reasonable to believe each of these approaches has its place, but "just say yes" is surely what got us into this mess to start with. On the other hand, "just say no" may work well if your product is shoes, but it's unlikely to be effective in today's dynamic and fast-paced business climate.<br /><br />Looking at it more closely, we can see a fatal flaw in the general application of each these perspectives: they're both one-sided. They're designed to create a "Winner" and a "Loser," and they always leave someone feeling dissatisfied with unmet needs. Another important limitation of the "Just Say Yes" and "Just Say No" philosophies is their immersion in a principle based on "<b>or</b>" rather than "<b>and</b>". We need something more balanced, something that can please all parties, and something that can create "win win" outcomes. You know, we need to leverage our synergies for win-win scenarios." Sorry! It's been one of those days. Seriously, we will benefit (and our "customer" will benefit) from an approach that recognizes and respects the full range of needs and strikes an appropriate and mutually satisfying balance. We need the Process for Saying "No".<br /><br /><b>The Process for Saying "No"</b><br /><br /><span style="font-style: italic;">Step 1. Echo the request</span><br /><br />It's critical right up front to establish a common frame of reference. To put it in Covey (<a href="http://www.amazon.com/gp/product/0743269519?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0743269519">The 7 Habits of Highly Effective People</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0743269519" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />) terms, we want to "seek first to understand." In addition, repeating the request demonstrates an empathetic inclination and lays the groundwork for expressing commitment to the requester's true objectives.<br /><br /><span style="font-style: italic;">Step 2. Say "no"</span><br /><br />Here's where it's easy to head down the wrong path and begin to get in trouble. Rather than beat around the bush when a request cannot be satisfied, it's best to simply be honest and clear. This avoids the risk of ambiguity and misunderstanding and begins to set the stage for the open communication that's so essential in negotiations.<br /><br /><span style="font-style: italic;">Step 3. Explain the rationale</span><br /><br />There's a reason why the request cannot be satisfied, and making that reason clear goes a long way toward validating dependency and establishing trust. Explaining "why" helps to create a foundational sense of "we're in this together."<br /><br /><span style="font-style: italic;">Step 4. Provide alternative solutions</span><br /><br />Now that we've demonstrated commitment, established a common perspective, and created goodwill, we can explore alternatives and discover a mutually satisfying solution. It's important to take the initiative here and show determination coupled with a willingness to be creative.<br /><br />By following the process for saying "No", it's possible for everyone to come out a winner. Not only are individual needs satisfied, but a degree of partnership is fostered that strengthens the relationship, increases transparency, allows vulnerability, and encourages trust. This is certain to make future exchanges even more productive and healthy.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-54761640043716951642007-12-02T21:49:00.000-05:002007-12-02T22:10:27.775-05:00Architects Are PigsRemember the story of the barnyard breakfast?<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZsQbPosr_gDB_gshkz603izfb9gTk3nLrJXUBQbbcCXcuhKACMdymKIHsiG7crJCaLZSyIlpTZmFA0avdddy6rK9_BL-v77ZJI0cMgskg0S6H3S6mtCEyKbjQLncI74BygRo7cPB-xuI/s1600-r/sizzle.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 185px; height: 122px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMZOcZ0R3vl7_xH4s88IA88lCdJ2eBsMtfd4zkpEIb0rw9ok6rf432D-1DoLg8dXS7XHxqGIryE7fTwLTxMgbjn7breLM8GIVA9ppnG84jpq8NOokd40lW4hV4zYJ7ZGE_GMHI_iK3yew/s320/sizzle.jpg" alt="" id="BLOGGER_PHOTO_ID_5139498374489568674" border="0" /></a><br />The chicken and the pig agree to co-host a barnyard breakfast for their friends. The chicken suggests they serve bacon and eggs. The pig quickly responds, "No way. For you, bacon and eggs is simply involvement. For me, it's total commitment!"<br /><br /><br />Leadership and accountability go hand-in-hand. As elaborated upon in <a href="http://blog.softwarearchitecture.com/2007/05/architect-is-accountable.html">The Architect is Accountable!</a> and <a href="http://blog.softwarearchitecture.com/2007/07/proactive-architect.html">The Proactive Architect</a>, the Architect is expected to lead by example. This sort of commitment means living in the trenches with the project teams, establishing goodwill, and earning respect.<br /><br />Another way of saying this is the Architect must possess "personal authority." This is quite different from "position authority" (which may or may not be present as a result of the title and role of Architect). Personal authority is a principle enabler of leadership and is critical to the effectiveness of the Architect. Decades of research have shown that personal authority is rooted in several factors, including certain personal and social characteristics. However, the number one source is universally tied to performance-oriented attributes such as ability, knowledge, accomplishment, commitment, and responsibility. <br /><br />As an Architect, one of your primary responsibilities is to influence. Your ability to provide influence is connected to the extent to which others view you as credible and acceptable - the extent to which you possess personal authority. And personal authority emerges from performance, visibility, and results - the kind of results that are only possible if you're in the game and personally invested.<br /><br />Are you demonstrating "Pig Commitment"?Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-87230587648910967262007-11-29T21:44:00.000-05:002007-11-29T22:02:46.268-05:00IASA/ITARC Communication TalkUploaded my talk on Communications from the IASA/ITARC Conference.<br /><br /><a href="http://softwarearchitecture.s3.amazonaws.com/C4_Communications_IASA_.pdf">http://softwarearchitecture.s3.amazonaws.com/C4_Communications_IASA_.pdf</a><br /><br />This talk elaborated on the 4C's of a good Software Architecture description:<br /><br /><span style="font-weight: bold;">Correct </span>- Accurate content describing the right architecture<br /><span style="font-weight: bold;">Clear </span>- Easily understood and meaningful to the stakeholders<br /><span style="font-weight: bold;">Concise </span>- Includes only the architecturally significant content<br /><span style="font-weight: bold;">Comprehensive </span>- Addresses the true breadth of architectural concernsBrian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-85865813248108432672007-11-21T12:51:00.000-05:002007-11-21T13:55:44.990-05:00Nurture the Freaks"How do you build organizations that are as nimble as change itself? How do you mobilize and monetize the imagination of every employee, every day? How do you create organizations that are highly engaging places to work in?"<br /><br />These are some of the questions being asked by Gary Hamel, author of the new book, <a href="http://www.amazon.com/gp/product/1422102505?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1422102505">The Future of Management</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1422102505" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />. The latest issue of the McKinsey Quarterly interviews Hamel along with Howell Bryan, a McKinsey partner and co-author of <a href="http://www.amazon.com/gp/product/0071490825?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0071490825">Mobilizing Minds</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0071490825" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />. In this interview, they discuss an emerging model for management that enables organizations to cope with the need for change and innovation.<br /><br />Of course, when I read questions like these, they're instantly translated to "How do we harness the imagination of every employee to design and deliver innovative and 'blow-the-doors-off' competitive solutions." Hamel and Bryan offer compelling insight into management's role, and you're encouraged to read the <a href="http://www.mckinseyquarterly.com/Strategy/Innovation/Innovative_management_A_conversation_between_Gary_Hamel_and_Lowell_Bryan_2065">full interview here</a>. Following are a few highlights.<br /><br /><blockquote>Hamel: "When you look at companies like Toyota, you see their ability to mobilize the intelligence of so-called ordinary workers. Going forward, no company will be able to afford to waste a single iota of human imagination and intellectual power."<br /><br />Hamel: "The combination of technology and talent is a powerful catalyst for value creation, but to take advantage of the Web's capacity to help us aggregate and amplify human potential in new ways, we must first of all abandon some of our traditional management beliefs—the notion, for example, that strategy should be set at the top. So I think Lowell is 100 percent right: in terms of managing creative-thinking people, you have to separate the work of managing from the notion of managers as a distinct and privileged class of employees. Highly talented people don't need, and are unlikely to put up with, an overtly hierarchical management model."<br /><br />Bryan: "These thinking-intensive people are increasingly self-directed. In fact, they're directed as much by their peers as they are by supervisors. The management challenge is akin to urban planning. The art of it is that you must enable people to make thousands and thousands of individual decisions about how to live and work, but you have to create the infrastructure to make it easy for them to do so."</blockquote>The ability to innovate - to generate creative ideas and deliver on their potential - is rapidly becoming the currency of our economy. Consider the rate of innovation in the consumer electronics space. I recently bought a new iPod. This handy little device sports a 160gb hard drive and costs $100 less than the measly 80gb model I bought less than one year ago. It makes me wonder. Is Apple's product this physical device, or is their "product" more the ability to conceive, design, and develop increasingly compelling and "game-changing" products. In other words, perhaps <span style="font-weight: bold; font-style: italic;">Innovation</span> is their product and the iPod is merely a byproduct.<br /><br />Increasingly, regardless of industry sector, innovation is the number one business need, and it's up to us to maximize the extent to which this requirement is satisfied in all our pursuits.<br /><br />Our role as leaders is changing (see <a href="http://blog.softwarearchitecture.com/2007/09/leadership-secret-sauce.html">leadership - the secret sauce</a>). Are we trading in the correct currency? Are we mobilizing and monetizing the imagination of every employee? Are we nurturing the freaks? As Gary Hamel puts it, "Going forward, no company will be able to afford to waste a single iota of human imagination and intellectual power."Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-76962129397912181352007-11-20T09:20:00.000-05:002007-11-20T09:21:14.114-05:00My BookshelfI'm frequently asked for book recommendations on topics ranging from patterns to people, leadership to lean, or SOA to SQL. I thought I'd collect all my notes in one place and provide the following list of what's on my bookshelf.<br /><br />These are listed in no particular order and some of the groupings are a bit arbitrary. If you could see my office, you'd understand :-o<br /><br />I hope you find the list useful, and I'd love to hear about your favorites.<br /><br /><span style="font-weight: bold;">Architecture</span><br /><br /><a href="http://www.amazon.com/gp/product/0131858580?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131858580">Service-Oriented Architecture (SOA): Concepts, Technology, and Design</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0131858580" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0132344823?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0132344823">SOA Principles of Service Design</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0132344823" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1591398398?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1591398398">Enterprise Architecture As Strategy: Creating a Foundation for Business Execution</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1591398398" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321112296?ie=UTF8&tag=softwararchit-20&linkCode=as2&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;camp=1789&creative=9325&creativeASIN=0321112296">Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321112296" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321154959?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321154959">Software Architecture in Practice</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321154959" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/020170482X?ie=UTF8&tag=softwararchit-20&linkCode=as2&amp;amp;amp;amp;amp;amp;amp;amp;amp;camp=1789&creative=9325&creativeASIN=020170482X">Evaluating Software Architectures: Methods and Case Studies</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=020170482X" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0201703726?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201703726">Documenting Software Architectures: Views and Beyond</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0201703726" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0131473794?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131473794">IT Architecture Toolkit</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0131473794" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321200683?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321200683">Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321200683" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0596006756?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596006756">Enterprise Service Bus</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0596006756" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321127420?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321127420">Patterns of Enterprise Application Architecture</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321127420" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0596006756?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596006756">Enterprise Service Bus</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0596006756" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><br /><span style="font-weight: bold;">Development</span><br /><br /><a href="http://www.amazon.com/gp/product/0201895420?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201895420">Analysis Patterns: Reusable Object Models</a><img style="border: medium none ; margin: 0px;" alt="" src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;o=1&a=0201895420" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201633612">Design Patterns: Elements of Reusable Object-Oriented Software</a><br /><br /><a href="http://www.amazon.com/gp/product/020161622X?ie=UTF8&tag=softwararchit-20&linkCode=as2&amp;amp;amp;amp;amp;amp;amp;amp;amp;camp=1789&creative=9325&creativeASIN=020161622X">The Pragmatic Programmer: From Journeyman to Master</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=020161622X" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0764543857?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0764543857">Expert One-on-One J2EE Design and Development (Programmer to Programmer)</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0764543857" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0201548550?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201548550">Advanced C++ Programming Styles and Idioms</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0201548550" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0977616630?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0977616630">Agile Web Development with Rails, 2nd Edition</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0977616630" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0123693799?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0123693799">Joe Celko's SQL for Smarties: Advanced SQL Programming</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0123693799" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0123735963?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0123735963">Joe Celko's SQL Puzzles and Answers</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0123735963" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0131495054?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131495054">xUnit Test Patterns: Refactoring Test Code</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0131495054" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><br /><span style="font-weight: bold;">Approach/Methodology</span><br /><br /><a href="http://www.amazon.com/gp/product/0201702258?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201702258">Writing Effective Use Cases</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0201702258" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321193687?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321193687">UML Distilled: A Brief Guide to the Standard Object Modeling Language</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321193687" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321150783?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321150783">Lean Software Development: An Agile Toolkit for Software Development Managers</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321150783" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321186125?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321186125">Balancing Agility and Discipline: A Guide for the Perplexed</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321186125" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321219775?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321219775">Agile Project Management: Creating Innovative Products</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321219775" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0131240714?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131240714">Managing Agile Projects (Robert C. Martin Series)</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0131240714" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321278658?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321278658">Extreme Programming Explained: Embrace Change</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321278658" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321458192?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321458192">Scaling Software Agility: Best Practices for Large Enterprises</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321458192" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/032126889X?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=032126889X">Managing Iterative Software Development Projects</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=032126889X" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0321197704?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321197704">The Rational Unified Process: An Introduction</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0321197704" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><br /><span style="font-weight: bold;">Leadership</span><br /><br /><a href="http://www.amazon.com/gp/product/0743269519?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0743269519">The 7 Habits of Highly Effective People</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0743269519" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0787968056?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0787968056">Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0787968056" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0787960756?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0787960756">The Five Dysfunctions of a Team: A Leadership Fable</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0787960756" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1422102505?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1422102505">The Future of Management</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1422102505" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0066620996?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0066620996">Good to Great: Why Some Companies Make the Leap... and Others Don't</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0066620996" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0385721706?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0385721706">The Wisdom of Crowds</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0385721706" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0743201140?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0743201140">Now, Discover Your Strengths</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0743201140" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0553803522?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0553803522">Social Intelligence: The New Science of Human Relationships</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0553803522" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0316346624?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0316346624">The Tipping Point: How Little Things Can Make a Big Difference</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0316346624" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1578512549?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1578512549">The Heart of Change: Real-Life Stories of How People Change Their Organizations</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1578512549" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/068815428X?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=068815428X">Gung Ho! Turn On the People in Any Organization</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=068815428X" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1401302378?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1401302378">The Long Tail: Why the Future of Business Is Selling Less of More</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1401302378" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0385512074?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0385512074">The Ten Faces of Innovation: IDEO's Strategies for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0385512074" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1422101657?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1422101657">Hidden in Plain Sight: How to Find and Execute Your Company's Next Big Growth Strategy</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1422101657" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><br /><span style="font-weight: bold;">Way Back Machine </span><span style="font-style: italic;">(but still on my shelf)</span><br /><br /><a href="http://www.amazon.com/gp/product/0932633439?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0932633439">Peopleware: Productive Projects and Teams</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0932633439" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/B000OLXPFW?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=B000OLXPFW">Object-Oriented Software Engineering</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=B000OLXPFW" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0136298419?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0136298419">Object-Oriented Modeling and Design</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0136298419" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201633612">Design Patterns: Elements of Reusable Object-Oriented Software</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0201633612" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/1556156502?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1556156502">Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=1556156502" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0131103628?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131103628">The C Programming Language (2nd Edition)</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0131103628" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/0070512787?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0070512787">The Elements of C Programming Style</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=0070512787" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" /><br /><br /><a href="http://www.amazon.com/gp/product/013937681X?ie=UTF8&tag=softwararchit-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=013937681X">The UNIX Programming Environment</a><img src="http://www.assoc-amazon.com/e/ir?t=softwararchit-20&l=as2&o=1&a=013937681X" alt="" style="border: medium none ! important; margin: 0px ! important;" border="0" height="1" width="1" />Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-74740563771564683412007-11-18T22:08:00.000-05:002007-11-18T22:17:55.304-05:00MDA and SOA are OrthogonalTo a certain degree, MDA and SOA share some common goals. Specifically, both offer the promise of isolating business/application logic from underlying technology/platform considerations. The anticipated result is significantly greater business flexibility as the business and technology aspects of the Enterprise can each evolve at their own pace.<br /><br />Technically speaking, however, MDA and SOA are quite different. Model Driven Architecture (MDA) is essentially a top-down approach to designing or modeling the enterprise. It "addresses the complete life cycle of designing, deploying, integrating, and managing applications as well as data using open standards" (<a href="http://www.omg.org/mda/executive_overview.htm">www.omg.org/mda/executive_overview.htm</a>). MDA encourages modeling of the various aspects of the enterprise - including data, applications, services, technology - and leverages a comprehensive repository that includes meta-data that supports decisions and communication about the Enterprise Architecture. Further, MDA specifies the modeling tools, schema, and "languages" (e.g., MOF, XMI, CWM, CIM, etc) for this "management information."<br /><br />SOA, on the other hand, is an Architectural Style "in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications" ("Service-Oriented Architecture: Concepts, Technology, and Design", Thomas Erl). SOA emphasizes design principles such as Abstraction, Autonomy, Reusability, and Composability (to name a few) that when taken together motivate and enable the decoupling of requirements for business processes from underlying implementation characteristics.<br /><br />As SOA has matured beyond it's deeply technical roots, and as the industry has gained experience with large-scale adoption, it's composition has naturally broadened to include important considerations such as infrastructure support, standards, governance, and other essentials. We've also watched as SOA has moved through the typical stages of hype, only recently starting to move past over-enthusiastic and unreasonable expectations to become a more realistic component of a balanced enterprise strategy. In fact, if memory serves, Gartner's "hype cycle" positions SOA at the front edge of the "Slope of Enlightenment," just starting the climb out of the "Trough of Disillusionment." As we continue to climb the slope, the definition of SOA will continue to broaden, and the essential supporting capabilities (modeling, governance, etc) will mature and stabilize. Likewise, tool support will reach more broadly across the enterprise and influence more of the operation. As this transition takes place, SOA will continue to assume its role in providing a common language and paradigm for the unification of IT and the Business.<br /><br />The result (slipping into opinion and conjecture) is that SOA will leave no room for the more rigorous and unwieldy MDA - even though they are technically orthogonal.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com1tag:blogger.com,1999:blog-4123173409120259026.post-68070230298497514122007-09-20T21:46:00.000-04:002007-09-20T22:33:58.218-04:00Agile Is Not "Make It Up As You Go"Much to my delight, there is growing recognition that the Agile movement has attracted more than a few constituents that leverage the great principles of Agile as an excuse to "make it up as you go". It's true that Agile enables and even encourages a system that responds to change and adapts efficiently in response to the collective assessment of the team in the context of demonstrable progress and up-to-the-minute (or up-to-the-sprint) evaluation of needs and opportunities. Good stuff. It's also true that Agile emphasizes people and collaboration. And it encourages empowerment and local decision-making. Really good stuff. Unfortunately, there are many examples where these valuable leadership characteristics are being taken to an extreme or taken out of context and applied in ways that can be damaging to the team, to the project, and to the business.<br /><br />I was speaking with a senior IT leader recently. This individual, for whom I have a great deal of respect, has not had much exposure to Agile and was telling me about an recent experience with a self-proclaimed "Agile" team. The primary take away from their close encounter of the Agile kind was frustration that months into a project the team could not even describe the most fundamental aspects of their objectives. It reminds me of that quote, "if you don't know where you're going, any road will get you there." Adaptation and empirical process controls are good things - incredibly powerful and valuable. But Agile doesn't mean "we have no idea where we're going or when we'll get there or which road we'll take." Agile in the absence of meaningful vision and direction is just hacking, and hacking gives Agile a bad name.<br /><br />Mike posted a nice writeup on how we might look at RUP as an effective framework for organizing Agile teams at scale. In this post, title <a href="http://appliedagileleadership.blogspot.com/2007/09/agile-heart-of-unified-process.html">The Agile Heart of the Unified Process</a>, he writes:<br /><blockquote>The secret to scaling Agile lies in doing just enough up front planning to ensure the teams understand the big picture of the product they are creating and have defined the significant mechanisms of communication between the various subcomponents. The RUP provides an ideal framework for helping a collection of small teams define what needs to be done in support of a large scale Agile development effort.</blockquote>Whether you follow Mike's advise or some other, be sure to know where you're going on an Agile project - and be sure you've picked the right road to get you there.Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0tag:blogger.com,1999:blog-4123173409120259026.post-19206461010568986782007-09-17T16:07:00.000-04:002007-09-17T16:25:24.523-04:00Leadership - The Secret Sauce<p>More and more it occurs to me that one of the most important ingredients in the secret sauce of leadership is the ability to create a situation where the people feel like they're responsible for their own destiny - that what they think (and believe) has an influence. I'm reminded of that Eisenhower quote, "Leadership is the art of getting someone else to do something you want done because he wants to do it."</p><p>One way we do that is by enabling and empowering the people to advance the cause - to invent and improve the means of accomplishing the goals. To do this, it's essential that the people understand and believe that the system belongs to them. As leaders, we should reach inside and create among the people a hunger and a quest for improvement of their system. The improvement then generates from the center and radiates outward. This is "inside-out leadership" or "leadership from the center" and creates a sense of ownership that leads to ridiculous energy… and ridiculous improvement… and outrageous performance.</p><p>Taiichi Ohno, father of the Toyota Production System ("Toyota Way"), said it like this:</p><blockquote>We need to use the words ‘you made’ as in ‘follow the decisions you made.’ When we say ‘they were made’ people feel like it was forced upon them.</blockquote><p>The results of this leadership style are tremendous. By harnessing the energy and intellect of the team, you not only benefit from the "Wisdom of the Crowd", you instill a sense of ownership and commitment that is able to overcome any barrier - take any hill. Author Gary Hamel speaks to this in his "Management Innovation" article in the February 2006 edition of the Harvard Business Review:</p><blockquote>“Only after American car makers had exhausted every other explanation for Toyota’s success – an undervalued yen, a docile workforce, Japanese culture, superior automation – were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.” </blockquote><p>There's a particularly meaningful nugget in that quote… <span style="font-style: italic;">Harness the intellect of "ordinary" employees</span></p><p>Adaptive and agile organizations are learning organizations. Learning organizations achieve outrageous levels of performance by harnessing the intellect and energy of the people through "inside out leadership" - the secret sauce.</p>Brian Sondergaardhttp://www.blogger.com/profile/02714290965708039030noreply@blogger.com0