You’ve probably read Getting to Yes and heard of Getting Past No, so why Getting Past “But”? Well, because “but…” is insidious, making it harder to get past than an outright “no.” The person who says “yes, but…” is ostensibly aligning with you. Ostensibly agreeing but for this teensy caveat—this objection that is a showstopper! It can be resistance in a subtle guise, seeming passive yet inherently active—the kind of action that is actively rationalized non-action. Or it can be genuine goodwill—indicating a real desire to orient with you, and active intellectual, creative engagement. The trouble, though, is that “but” can become a barrier. We need the attitude that looks beyond “but.” If we look only to “but,” only to the objections, the reasons why not, we stop there. We need to look to what we want to accomplish, then figure out how to get there from here. We need to look beyond “but” to get past “but.” Yes, this is the stuff of “kindling the collective mind,” engaging others in seeing how we would like things to be, then engaging their creativity in resolving how to get there.
I’m told “I agree with you, architects should play an active role in requirements, but reality in my organization is that the structure and process doesn’t allow that.” Yes, that reality is hard to change. And it will not, so long as the one person who could begin to make the change, the person who sees that the change is needed, doesn’t start to lead the change! First, to see the need, then to help others see a better future, then to enroll them in creating that better future.
This by way of an architect’s signature on an email I received this evening:
“Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people.”
George Bernard Shaw
Yes, change can be hard, and it can take a long time to even get to the point where people recognize the need for change. It took Madison five years to get the parties to the table to create change. Hopefully it can take us less time to restructure the status quo in software development. Our Getting Past “But” paper is one resource you have to help shift perception and expectation. The Agile Movement also helps underscore the importance of multi-disciplinary teams. If your organization’s approach to scale and complexity is to do just enough requirements and design upfront (for example, to spin off concurrent teams with enough context), you can still leverage the learning that the Agile Movement has embraced—multi-functional teams, iteration and stakeholder participation allow more concurrency to happen earlier, with better outcomes.
]]>innovation, the circles of innovation model, the innovation process, and what all this means for architects.
scaling agile development projects with VAP (emphasizing just enough design upfront or JEDUF).
These map roughly to the first and second halves of the report, though we encourage those interested primarily in the material in the second half to also read the first half. What follows is a brief outline of the contribution of these two parts of the Getting Past “But…” paper.
Innovation and Architects
Innovation is rampant, and clearly companies big and small are innovating apace. At the same time, many companies are disappointed with the return on their innovation investments. Industry incumbents are adapted to the status quo and defend their inertial tendencies with “but..”: but we aren’t chartered to do that, but that’s too risky, but our customers aren’t asking for that, but that would cannibalize our market. Focusing on immediate releases and incremental improvements, thwarts competitive landscape reshaping innovation which then tends to come from outside, often from start-ups.
Getting past “but…” takes a shift in attitude. It is true that this shift is fostered by empowerment, with an innovation culture established by top management. Google is the prototypical example there. It is also true that the shift can start with the individual. The creation of masking tape (the 3M story starts around minute 21 of Scott Berkun’s presentation) is just one example where the inventor used his own initiative and limited budget to fly a skunkwords project under the radar. We need to recognize that generally there isn’t a shortage of ideas. And, in aggregate, there isn’t a shortage of willingness to take risks—witness the number of failures, including startups. What we need are more effective ways to get good ideas on the table, sift for those that make good business sense because they create high customer value that can be used to build differentiated identity and strategic advantage in the industry, put them through early, quick and cheap failure/improvement cycles, and get more and more talented peoples’ heads in the game to build the system.
Our Getting Past “But”: Finding Opportunity and Making IT Happen report speaks to role and process changes that empower design teams to create a new competitive basis through differentiating innovations. You can download a complimentary copy from Cutter Consortium at http://www.cutter.com/offers/findopportunity.html.
In this paper, we take the position that architects need to be part of, if not lead, the innovation team. The architect’s role is to help the business identify opportunities to create value through capabilities that technology brings to the table. This leverages the unique perspective of the architect into technology and the organization’s technical capabilities, but it also leverages the architect’s unique skills in system thinking and modeling.
VAP and Scaling Agile
VAP (the Visual Architecting Process) is all about being agile even when the complexity of the system, and the organizational unit(s) building it, demands just enough upfront design—for example, to launch concurrent agile teams. What VAP emphasizes and enables is parallelizing the requirements and architecture iterations, with intensive stakeholder involvement as pertinent to the quick cycles. VAP can be applied during coding cycles, but for complex systems, early VAP cycles use the cheapest possible artifacts (e.g., models and prototypes) for learning quickly about stakeholder value and architectural challenge. This concurrency, together with the principle of stakeholder involvement (including but not limited to end users), is a major value and contribution of VAP.
We write about JEDUF and agile architecture in the Getting past But paper. The content of the report is so important to the conversations we’re having, to the challenges of organization after organization as the hype around agile pushes larger and larger projects to experiment with agile development. As we do so, we need to leverage all the lessons of our histories creating complex systems, as well as the lessons and values of agile development, to adapt a process that works for concurrent development of complex systems.
References
This synopsis derives from writing in Ruth Malan’s (almost daily) architecture journal.
Ruth Malan and Dana Bredemeyer, “Getting Past “But”: Finding Opportunity and Making It Happen.” Enterprise Architecture Executive Report, Cutter Consortium, August 2008 You can download a complimentary copy from http://www.cutter.com/offers/findopportunity.html.
]]>The Wikipedia community describes Conway’s Law like this; I paraphrase it like this: if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. The organizational divides are going to drive the true seams in the system.
The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition is what typically drives work allocations. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational dissonance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete–structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.
One could say this is part of the innovator’s dilemma. Sustaining innovations, that is, incremental improvements within the cast of the architecture, are what the organization is adapted to be good at. But when a breakthrough innovation demands a new architecture, a new organization (unencumbered by power trees that grew up around the old architecture) tends to be more fleet in bringing the innovation to market.
Another implication of Conway’s Law is that if we have managers deciding on teams (what they’ll do, who will be on them, and how they will relate), and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture. They determine system chunks (services or components) and capabilities by deciding who will build what.
Conway’s Law also kicks in if we take an initial guess at the system decomposition (a first-cut conceptual architecture), allocate subsystems to teams, and sally forth–the team boundaries will tend to become the boundaries within the system. Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks. Yet, architecture is where we address cross-cutting concerns, or at least those that needs-must be addressed with a system perspective so that when it comes time to compose the system it will have the properties stakeholders care about, rather than emergent properties that may or may not suffice.
Roles are defined by their responsibilities and associated decisions. Architect is a role. Any person may play one or more roles. That is, the architect role may be shared among a group of people (as in many agile project teams), or one person may hold more than one role (as in many small teams, especially in startups). This may be overt and declared. And it may be the result of decisions that are actually effected. If management decisions determine the architecture of the system, they are in effect its architects. If developers determine the architectural decisions, they are in effect its architects.
“Duh!” you might well be saying. Yes, a lot of what is absolutely common sense when it is put plainly, is so obtuse in the face of perplexifying reality. Simply witness all the heated arguments and misunderstandings you get around the topic of the role of the architect.
But what does it mean? Architecture needs to happen across the interfaces, and this also means across the system/organization interfaces. It means that system architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other.
Other references:
Why do we need software architecture (how architecture serves organizational and technical purposes)
Who needs carrots anyway? (about the iron triangle and the interface between management and architects)
]]>I so like The Wheel on the School! The team was chartered: wonder about storks. The team went off, and in their individual styles, wondered. They created a shared vision. Then they each went off in different directions, like the spokes of a wheel, but with a common vision unifying their search for a solution. The whole village got pulled into the creation of the solution, at different points. The team told vivid vision stories to motivate and inspire various people along the way. More and more people got drawn into creating the solution; taking risks, doing what it takes. The core team, working like cogs, pulled in teams of teams. Sometimes all working together, sometimes as smaller teams. Fluid, dynamic, ever-changing teams. Through action, they made the vision real. People changed; changed their self-concept, changed the communities concept of them. In changing how they viewed themselves, in changing how they viewed others, they built the team. A team needs diversity and a team is transformative; or it can be. They made their vision real: they wondered, they created a shared vision, and they set the wheels of action in motion.
This is Kotter’s 8 steps of leading change in one delightful story you can even share with your kids. Or have them teach you. An open mind. A willingness to wonder. A willingness to think outside the box of convention. If you want to create, to lead, and you don’t relate to this book, please do tell me! The first 3 chapters on creating a shared vision will either have your attention, or you’ll be lost in translation. Not so much to invest then. And, if you find it useful, by all means tell us what lessons you found radiating from this gem of book.
While I’m recommending books for leaders, I also really like Stephen Denning’s The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative, Jossey-Bass, April 22, 2005. I see he has a follow-up book due out in October called The Secret Language of Leadership, (2007).
]]>If you’re interested in Agile and Architecture, here’s an interesting read, including the comments: The Demise of the Gantt Chart in Agile Software Projects, by Tate Stuntz on July 31, 2007. I have to agree with David Christiansen: “I’m not convinced there is such a thing as a methodology or process that can produce good architecture.” People create great architecture, just like it is people that create great software systems. But are there things we can do to create better architectures, and better software systems? Of course I believe there are! That’s where process comes in.
In manufacturing we learned that if we inspect quality in at the end, the cost of quality (a term that refers to the cost of poor quality that leaks through the inspection process, as well as the cost of removing found defects) is much, much higher than if we find potential quality problems at the source, to ensure they aren’t inserted.
Architecture defects, those that have diffuse impact across the system, are so expensive they are hard to recover from when they are only discovered once the architecture is hard-cast in code. Hard-cast, I say, because though we think software is pliable while we are writing code, the volume of it quickly amasses, and with it sunk cost and sunk time. And we don’t, as an industry, understand sunk cost and sunk time terribly well! It is a huge reset to go back and rework the system to accommodate an architectural change of any significance. Because we perceive software as highly mutable, we think we can recover if we scramble, but our accommodations to the code make it ever more immutable as the structure erodes to the point where it is hard and unpredictable to change.
More expensive still, have to be products that are defective in concept, set to miss the market. Getting the product or application concept right–the value propositions that will deliver customer advantage and delight–is not a feel-our-way-as-we-build kind of thing. It is a strategic matter. Or at least, get the strategy wrong, and all the tweaks in the world are going succeed only by amazing luck and sheer heroics.
And yet, it seems to be asking for suspension of disbelief to ask for time on a project where all that is being produced is models, diagrams, stories, even if this work is toward a minimalist set of strategic decisions. Putting features in front of users, why, that is what creating software is all about. That is where we can see progress.
Still, if progress is moving towards a better sense of what our customers value, across use contexts, and all that decision space complexity, then we can make a lot of progress quickly and cheaply with models (and mock-ups and proof-of-concept/prototypes). And by exploring how those features play out over our posited architecture structures, we can refactor early, cheaply, while all we are changing is models and descriptions.
To help people create great architectures, our process needs to:
lead us to work in an integrative, collaborative way (without becoming a “committee”)
explore and visualize value opportunities and value delivery mechanisms, to establish architecturally significant requirements and architecture strategy
learn quickly through iterative cycles.
Yes, this is an agile process, if we make models recognized citizens of the software world, with full rights to authenticity and budget! In all we do, we have to find a good balance. Our models should not be belabored, certainly not early on, by putting in too much detail or trying to make them look pretty too early in a tool where pretty is hard to do once, let alone with changes.
We also need to open up our “agile” concept of customer. I highly recommend Hidden in Plain Sight. I’ve also written about delight (key to customer advantage) various places in my architects/architecting/architecture journal notes (e.g., Vitruvius and delight, circle of excellence and (skipping the first paragraph) Zappos demonstrates that IT Does Matter).
What we are trying to do is surface and understand value propositions that users and other stakeholders find compelling. And find and improve the structures (architectural components and mechanisms) that will support the system through the sprints leading up to the first release, and beyond.
]]>
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In essence, informal, iterative, adaptive processes that rely on the collaboration of empowered individuals are strongly favored over formal, bureacratic process and its accoutrements (plans, contracts, comprehensive documentation). If we overlay these values with values for enabling dynamic teaming, value delivery and risk management, we have the value-set that underlies the Visual Architecting Process.
Short iterative cycles, early involvement of stakeholders, and visualization, allow for quick learning, early direction setting and iterative direction correction and refinement. But this learning is done with models as long as they are effective, reducing the cost of change as the architectural design is explored, refined and elaborated. Along the way, the architecture is documented, both to aid the architects in thinking through approaches and alternatives, and as a communication tool to get input and feedback from a broad set of stakeholders.
The process promotes early discovery of opportunity to innovate and differentiate, and builds alignment and motivation through a strong, shared vision and high-level system design that identifies system building blocks that, for large systems, become the units of agile development, allowing further innovation and experiment, with generally lower cost of change—lowered by isolating the impact of change.
This process then, allows us to integrate the best of agile software practices along with other practices used to get complex products created in reduced time—namely, allowing more people to be effective, productive and creatively engaged in building the system, because they have clear commitments to and from the system via the system design, and, yes, its documentation.
Embrace agile development and refactoring. Just start with models, work with all of the agile philosophies while the team is using models and document with sketches (visual and verbal) of the overall system and the key architectural mechanisms. Some of our lessons are learned the hard way, through discovery that necessitates refactoring at the code level. Others can be discovered by modeling the system and refactoring at the conceptual architectural element (module, component, service) level. Others are more apparent; we have after-all, some experience building software systems! Yes, the ground is constantly shifting under our feet–the competitive landscape, and the technological landscape, keep changing, sometimes in revolutionary ways. But at the same time, dominant designs emerge that see us through periods of system evolution.
Naturally, I’ve defended (just enough) architecture documentation various places:
Architects on a Pedestal–or Architects for Target Practice? This piece is intended to plead the case for documentation within an agile culture—not “comprehensive” (whatever that may be) documentation; but rather enough documentation to ensure that the goals of the architecture are achieved, taking into account that the architecture is long-lived and its goals encompass more than a release cycle.
Architecture Documentation: Courage to fly in the face of convention
This piece is intended to plead the case for documentation within an agile culture
Also related:
On Agile and Documentation
Do Agile Methods Require Documentation? by Geoffrey Wiseman, July 18, 2007
Agile/lean Documentation: Strategies for Agile Software Development, by Scott Ambler, last updated July 15, 2007
and while I wouldn’t toss the proverbial baby out with the bathwater:
Are Agile Development Practices Detrimental to Architecture and Design? by Amr Elssamadisy on July 17, 2007
Colm Smyth has a series of posts titled “Debugging Extreme Programming–Agile not Fragile” that is architect-friendly; see, for example, Refactoring, On-site Customer and Metaphor.
]]>
Here’s a status update on where things are at on HelpMatch.
HelpMatch Vision and Strategy
We are working on a “vision pitch” slideset; Al de Castro currently has the baton on that. This will be available for review and reaction shortly. I’m thinking it might be an idea to create a vision “webcast.” We will also use the HelpMatch wiki and HelpMatch blog for sharing and refining the HelpMatch vision.
We have worked an initial draft of the Identity (Mission, Core values and principles, vision) and Value Propositions, and have done an initial batch of work on competitive analysis, context analysis, etc. feeding into this strategy work. We still need to do more work on the capabilities tier of the strategy map, but it is already clear that a collaboration environment that will support a highly distributed team of global contributors to HelpMatch is a key capability area. Constraints like no immediate budget, and utilizing a flux workforce of volunteers are also clearly part of the picture.
Next Steps
Currently, this strategy work is hosted on the HelpMatch area of the Bredemeyer site, and I need to consolidate emerging thought with prior work and reflect the current state of the vision and strategy on the HelpMatch wiki. At our next face-to-face meeting in the Indy Architects Group, we’ll share a draft vision/strategy and use that as a starting point to refine the vision and strategy and create a draft roadmap.
We have taken a stab at Context Maps in various forums, but we need to create a Context Map for each distinct Use Context, and an overall Context Map that captures and illuminates the big picture landscape for HelpMatch.
A cut has been done at competitive analysis, but we need to extend this work to community/social networking sites, and drive it to a deeper level of analysis.
We need to do more work on the capabilities tier of the strategy map.
We need to share, elaborate and validate this work, and formalize a business plan.
HelpMatch.org Incorporation and Non-profit Status
We are actively exploring in this area, reaching out to connections who are or have been members of a Board of Directors for a non-profit, in part to learn lessons from those who have learned them the hard way, and in part to get candidates for the HelpMatch Board of Directors (BoD). We recognize we need to incorporate and file for non-profit status. But we need to form a board. And we need a good lawyer who is willing to do some pro bono work on this for us so we do it right.
Next Steps
Draft board selection criteria and identify candidates
Identify and work with a lawyer on articles and bylaws for the HelpMatch organization
Draft 501(c)(3) application
Persuade BoD candidates to invest their attention and energy in HelpMatch
and do whatever else is needed to prepare for and hold our first meeting of the Board of Directors and formally incorporate HelpMatch, and get non-profit status!
HelpMatch.net Collaboration Environment
Jarvis Ka has set up the HelpMatch wiki, and it is just waiting on me to add some starter content and then we’ll release it to the broader community on HelpMatch.net. Jarvis has also set up a HelpMatch blog. Carl Ozkaynak has set up a HelpMatch Google Group. Jarvis has been setting up conference call-in meetings using Yugma, and we’ve had several evening meetings working on the vision and the collaboration environment/wiki/etc.
Next Steps
In addition to these immediate enablers of start-up work, we are also advocating either finding (if its out there) or creating a collaboration environment needs assessment for distributed strategy and architecture work, with product comparisons, to help us set up the environment that will support collaboration among the teams of teams that will design and build HelpMatch.
If you know of such an assessment (or even point assessments for different aspects of this collaboration space) or have an interest in contributing in this area, please do let us know about them. Following Kevin’s suggestion, what we do here will be documented on the HelpMatch wiki, so that the community can keep it updated as the space moves, since it is such an actively evolving area.
HelpMatch Architecture
Recognizing that we have made a number of passes at the business strategy, but we are not done there, we are ready to start to identify architecturally significant requirements areas and architectural challenges, with a view to a first cut at architectural strategy. This whole space is still fluid, but this is as it should be. We shouldn’t begin to work on architecture after the strategy is as immutable as concrete reinforced with rebar–which is what we get, once egos get all wrapped up in a “perfect” strategy formulation. We want the architecture strategy to inform the business strategy, and the business strategy to inform and provide direction for the architecture work.
Next Steps
Create the initial organization in the wiki to create placeholders for the architectural work.
Identify what complementary capabilities we need on the Architecture Leadership Council.
Begin work on stakeholder value propositions and system capability requirements and system constraints, to make decisions about the scope of system, and scope of different stages of the system roll-out.
Begin work on the architecture strategy: identify architectural challenges and principles, architectural style, organizing concepts and metaphors, and possibly key technologies.
then drill down, learn, refine/elaborate, etc…. oh, and build the thing! ☺
Feedback: What do you think? What’s missing (bearing in mind that we want to lay a solid foundation for the organization and for the architecture work)?
]]>
Let’s explore the HelpMatch value proposition through scenarios or vignettes describing how HelpMatch could be used. I would like to get to more vivid stories, but here’s a start that will seed ideas. Please remember that we are in vision exploration here. We try to be specific and vivid, to be compelling and explore possibility. But we will need to go through scoping to set system bourdaries and feature sets for early versus later releases. Then we will need to refine our understanding still further. We are explicitly encouraging exploratory, out-of-the box thinking at this point.
After the Tornadoes
Tornadoes hit communities across the Midwest and Southeast killing at least 20 people, including 8 high school students. What can anyone do, and how could HelpMatch help?
How about this: a family member or friend of someone impacted by the tornadoes gets on to HelpMatch and forms a “project” (we will settle on tags later) to co-ordinate assistance. For those who lost homes and possessions, it might be easier to see how we can help: the project coordinator can enter needs and establish credibility through their network, and their network’s network, and out as far as trust and the desire to help reaches.
On the need fulfillment side, one way this could work is as follows: Those who want to help, can go to HelpMatch, and register to be reached through the links in their network to a source of need associated with the tornadoes. (This will test out the theory that it only takes 5 links to reach someone else!) Then they can search the entered needs and decide how to help–with items they already have to donate, or by coordinating a drive to collect/fund these items. For example, my kids school could sign up to replace books or a computer, or other equipment lost in the school hit by the tornado.
For those who lost loved ones it might be harder to imagine what we can possibly do. But to the extent that anyone can figure out what could be done to help, in little and big ways, that person could form a project to co-ordinate that help. The project can be local, and co-ordinate care being provided by a close group of family members and friends. Things like meals, providing childcare relief for younger siblings. And it can be bigger, and more distributed–helping to raise funds to help the family with counseling and with time off from jobs, or using the network to put the families in touch with grief counselors and other families who have lost a teenager and who have found ways to cope with the loss, and so forth.
The point is, as soon as we have “the obvious place to go” on the internet, and a set of tools for individuals, communities, organizations to form “help projects” or “sponsored networks” to coordinate needs and matching help, then we have a powerful mechanism for help to assemble as needed by the situation! And if we have a ready community of technical people, then as new ways to serve needs emerge, we can act to put the tools to support that help mechanism in place. So the HelpMatch solution set can grow organically as we envisage the full power of help networks through actually using help networks to match help to need–all over the world!
Room to Read
Let’s take another situation. One where an individual forms a help community to raise funds or goods for an established organization, like Room to Read. Say “Maybel” wants to raise the funds needed for Room to Read build a school in Nepal; she could use HelpMatch as the rendezvous point for the help community she forms and champions.
She would create a project page. Then she could:
tell the compelling story of the need for the school, maybe even put pictures or video clips on the project profile
use her project page as a bulletin board for announcements about the project
put a blog on the project space, to keep her help community up-to-date on developments, and to allow her community to comment and offer her suggestions, etc. (what a concept! chuckle)
put a donations button, and a “how we’re doing against target” gauge showing level of donations to date, on the project page
get visitors to that region to stop by the village where the school will be built, and get “on-the-ground” stories and photos, to make the story still more compelling and keep it right up-to-date with what is happening as the school gets built
broadcast an invitation to join her project to her network of friends on HelpMatch, and email her network of friends not yet on HelpMatch
make her project open, so any of her friends could broadcast to their friends, and on through the extended network, finding people to help make the dream of a new school real for a village that desperately needs one
put an icon to sell John Wood’s book on the project page, set up so that the Amazon Associates (or other) referral fee goes to Room to Read.
And I’m sure Maybel would come up with lots of other good things she could do, with the help of some technical friends, to rally her extended network around her cause and give them concrete ways to make a difference to it.
HelpMatch: Tools for the Help Community
HelpMatch will put quite sophisticated on-line community tools, as well as the ability to manage an inventory of donated goods or services, in the hands of help projects (individuals, and individuals working on behalf of individuals or organizations). It is like giving ad hoc as well as more formal help projects an IT staff!
Room to Read keeps overhead absolutely barebones so that it has an extraordinarily high proportion of donated funds going to the cause rather than the organization that supports the cause. HelpMatch would give people, and even organizations like Room to Read, the online community space tools that they would not otherwise have, due to their focus on keeping administrative and fund raising costs low. Then not only can Room to Read have more information, coordination and network marketing support to raise funds for their good work, but other organizations who have invested proportionately more in fund raising could use HelpMatch to reduce their costs and have a bigger portion of their donated dollar go to the cause they serve.
Exploring Other Scenarios
We welcome other ideas on how HelpMatch could:
i. directly, personally help individuals who need help
ii. provide support to individuals and groups who are trying to help individuals or groups in a situation of need.
]]>
i. collaboration tools: wiki and blog; other? ii. hosting service that works with your blog and wiki platform choices
If your ideal solution costs a lot, what do we put in place in the interim, while we get the organization side set up to take donations?
If no-one signs up to move this forward by Friday March 9th, I’m going to make unilateral choices! That, my friends, is a threat! “All the important mistakes are made on the first day” (Rechtin, 1991) and I’m happy to make most of them! But, you’ll have to live with the consequences, so in the style of the best architects reacting to this challenge–which I have stolen from one of the best technical managers I ever worked with (Anthony Dicolen)–I am sure you will rise to the occasion and save the community from me setting up a legacy you have to suffer with!
If you know someone who should be involved (like, say, they could donate the hosting service without dictating how the community-at-large needs to move forward; for example, hands-off on dictating technology choices without building community buy-in) do motivate them to pitch in here! Do whatever it takes–buy this person lunch, harangue them mercilessly, etc. This whole entire HelpMatch initiative is going to give you plenty of opportunity to practice your architecting skills. Let’s start here–persuade and influence!!!
Go to it:
]]>
Well, bigger. Add an “eBay” for donating and finding goods to help those in acute or chronic need, and you’re getting closer to the potential. Big huh? Well, think bigger still! Think of Room to Read. Think of microfinance networks. Think of anything you can to do to help, and organize a community around. The HelpMatch technical network will build the tools to create and run that community.
We are only limited by our ability to draw on analogies and experiences, because the creativity of the technical community is huge, the desire to learn and build in the technical community is huge, and the desire to help is a big as the need for help!
(I expressed some hesitancy on the willingness of our technical community to really ante up and make this happen, and it was Craig Jordan who took me gently but firmly to task, giving me the words: the desire to help is a big as the need for help.)
Carpe Diem: Seize the Day
HelpMatch, as a social networking space focused on providing help to those in chronic or acute need, has a window of opportunity that will close as other kinds of solutions are put to the market survival test. If we architects want a great big sandbox of an application, one that can truly make a difference in the world, then we need to seize the day!
I have registered HelpMatch.org for the HelpMatch help network, and HelpMatch.net for use by the technical community forum as we architect and build HelpMatch. I would like to very shortly have HelpMatch.net launched with community conversation/collaboration tools like a blog, wiki, etc. So, areas you can immediately help in are:
We need to get the vision statement pounded into shape quickly, so that we can form a Board of Directors and get HelpMatch formally launched as a non-profit organization that can take donations to get infrastructure in place. In addition to the Board of Directors, I’m suggesting we form an Architecture Leadership Council, and hold an “indaba” pretty soon. (indaba n. A council or meeting of indigenous peoples to discuss an important matter.) But this needs to be an open process, so if you disagree on how to organize for effectiveness here, please do comment on this post!
Again, we need the vision in place to do this. I’m hoping the Indy Architects Group will give some face-to-face time to this. Of notable mention–Al de Castro and Barry Crist, as the two primary/consistent sources of inspiration for HelpMatch ideas, and also Jeff Price, Gene Shin, and Kurt Kirkham. We also have new members who are just joining.
Architecture workshop attendees have worked on facets of HelpMatch, from vision to architecture, and in this post I am representing a lot of good ideas that have come from many, many people over the past 18 months or so.
There’s No Time like the Beginning to Make a Difference
If you have contacts with philanthropists who’d like to help people help each other, please put me in touch with them. This is an opportunity you can offer your contacts, and there is no time like the beginning to make a difference! While it will be good to have people involved on the HelpMatch organization side who are committed to putting real time into this, money will also help speed this engine for social change up the network effects curve!
As soon as we get some collaborations infrastructure in place, we’ll all have to start serious viral marketing to create the space where our technical networking habits can translate into goodness for humanity–personal, individualized yet massive scale help! What a vision!
Be a Link in the Chain Reaction
You can stand on the sidelines and observe, and be part of the damping force of disbelief. Or you can pitch in and make this happen. You have the power to make this technology’s biggest contribution to the plight of poverty and disaster, chronic and acute need, at the individual, family, community and organization level! Each person who reads this and does not do something active to contribute, shares responsibility for inertial drag. You are the first link in the chain reaction that will spread HelpMatch around the world. Each person who acts, shares responsibility for beginning the network process that this needs to reach its potential. Your involvement will give you the satisfaction of seeing this through its crucial beginnings, setting in process the technology hub that will link people to people committed to making a difference.
You can start to connect the flow of influence by linking to
Architect a Better Future
Very soon we’ll have the HelpMatch portal up and running, but in the meantime, why hold back? If you have something against my facilitating getting this ball rolling, let’s talk about that. If not, link! Or, alternatively, create your own statement (and tell us where it is, so we can point others to it)! The least you will get is embarrassing me if I idle instead of playing a role in getting this into high gear! But the time is now! This is our defining moment!
Yes, this is daunting: “The most serious mistakes are made on the first day.” “The end depends on the beginning!”
And it is exciting too: “Begin with the end in mind.” The end, my friends, is the obvious place to turn to give and receive individual help: to connect directly, or through people and groups we trust, to those we can directly help. Technology is ready for this. It just takes some leadership, initiative, and yes, hard work with a hammer (see Bono’s commencement address). We are the architects of a better future.
We Need YOU!
So, give us your words; refine these words; let’s build the vision together.
Yes, we will have to scope and stage what we deliver as we build HelpMatch to its potential. But there is a big world-shaping opportunity here. Little seeds growing into huge maple trees all over the world, starting with each bit of contribution that you make now! Throw your idea seeds into the soil of HelpMatch.
]]>