brenda michelson's technology advisory practice
Over on Active Information, I wrote a post inspired by a recent consult. As I was thinking about the post, and the consult, I scribbled and then preview tweeted the following:
“Data isn’t just a mechanism to manage the business you have, it’s a tool to learn what business you could be in.”
Read the post. Implement the message.
Five years ago, I published my Event-Driven Architecture Overview on the Patricia Seybold Group Research Service as well as on elemental links.
Without question, the Event-Driven Architecture Overview is the most popular piece I have written. Because it is architectural, rather than technical, it remains relevant today, and will continue to help practitioners for the next several years.
To celebrate both the 5th Anniversary of the Event-Driven Architecture Overview report publication, and the rising interest in event-driven architecture and event processing, I’m re-issuing the core of the original paper in a traditional, portable, and easy-to-print format.
Staying true to the original, the re-issued report explains key event concepts, walks through event processing flows, and identifies the major implementation components of an event-driven architecture. I did update the event processing provider footnote to reflect current players.
The re-issue includes a new introduction as well as the requisite “About Brenda and Event Processing” page.
The report is free to download, no registration required. If you like it, pass it on to your friends and colleagues.
Download the 5th Anniversary Edition – Event Driven Architecture Overview. (PDF)
I picked up the Fall 2010 issue of Rotman Magazine because it is focused on complexity and uncertainty, two concerns of change-friendliness. Before I reached my intended target articles, I discovered an interesting Thought Leader Interview with Elinor Ostrom, Nobel Laureate in Economic Sciences.
In the interview, Ostrom speaks to two hard problems, the challenge of dealing with common-pool resources (CPR) and how to approach collective action dilemmas. While the context of the article is averting massive climate change, I found aspects applicable to classic business and IT issues. Particularly, the management of common pool resources. According to Ostrom:
“Common-pool resources, on the other hand, are any kind of resource where it is difficult to exclude anyone from using the resources, and where my consumption withdraws from the ‘pool’ that is potentially available to others. For example, with a fishery, the fish I remove from the system, you can’t catch. At the same time, it’s difficult to exclude anyone from using a CPR, and people will benefit from it whether or not they contribute to it. Theses two characteristics of CPRs are related in many ways, and when people talk about the ‘commons’, this is what they are referring to.”
In business-IT terms, the basic common pool resources are budget dollars and talent time. Some might add services of SOA and Cloud Computing, but the end of day resource limitations on SOA and Cloud services comes down to time and money. Who will pay for the change to Service X? Can we afford to scale service Y? Why must marketing wait on a customer service change to Service Z?
To deal with these management and allocation issues, we (IT) set up steering committees, governance boards, policies and waiver procedures. Most often, an IT representative – CIO, Relationship Manager, Chief Architect – sits at the center of the policy and decision-making processes. Even in the best situations, there is always a disappointed constituent, and often, lingering ill will.
There has to be a better way. Well, in her research, Ostrom has identified 8 design principles found in robust common pool resource institutions:
For CPRs that are part of larger systems:
What struck me about Ostrom’s findings is that the appropriator, the resource consumer, is at the center of the policy-making, monitoring and enforcement processes of effective common pool resource systems.
What can we learn from this? If (forgive me) we think of IT as a fishery, with the fishery infrastructure, processes and species specialization under the management of the CIO and team, could the fishing, consumption of IT goods, services and time be better governed by those hungry for service?
Or, would an appropriator-led governance regime result in widespread fishery failure?
Discuss.
Like many, I have the bad habit of multi-tasking my reading, so items don’t move to the finished stack as quickly as I’d like. However, a book that grabbed my full attention is Switch, How to Change Things when Change is Hard, by Chip and Dan Heath.
Switch is not your typical change management tome. There’s no 10-Step Plan or Come-to-Consensus moment. Instead, the Heath brothers present a clear 3-part framework based on scientific research of how the human brain works. In short, the framework advocates appealing to individual’s rational (Rider) and emotional (Elephant) sides, and shaping the change path.
The book is broken into three sections – Direct the Rider, Motivate the Elephant and Shape the Path. Consistent with their earlier book, Made to Stick, and their Fast Company column, Switch is replete with real-world anecdotes about identifying, motivating and executing difficult changes.
One story that stuck out for me was Jerry Sternin’s work in 1990 with Save the Children in Vietnam. Save the Children was invited to Vietnam to combat malnutrition. However, when Sternin arrived, he was given "six months to make a difference". This deadline made the research Sternin collected on malnutrition root causes — poverty, lack of clean water, poor sanitation and nutrition ignorance — "true but useless" (TBU).
Sternin didn’t have the time or money to address the underlying issues. He needed to identify a more direct way to make a difference. Forgoing the typical "focus on the problem" route, Sternin set out in search of bright spots. Sternin sought out well-nourished village children to learn how they defied the odds. Once identified, Sternin studied how these homes varied from the norm, on the lookout for deviations related to nutrition. Through observation, Sternin was able to identify differences in what and how the well-nourished children were fed.
Instead of issuing a proclamation of his findings, Sternin created a change path. Sternin instituted a mothers-teaching-mothers community program to change feeding habits. Making these seemingly small adjustments – number of meals per day, individual servings, sweet potato green and shrimp supplements to rice — dramatically improved childhood nutrition in the studied villages, and then spread throughout the country, eventually reaching 2.2 million people in 265 villages.
Besides the humanitarian aspect, what appealed to me about Sternin’s story was the problem solving technique. Instead of getting lost in "true but useless" (analysis-paralysis) Sternin identified and exploited bright spots. In a later example, a similar technique is described as Appreciative Inquiry.
Reading Switch, I picked up techniques related to change and solving hard problems. The latter was a pleasant surprise for me. If your work involves change, hard problems or the combination, I highly recommend Switch.
As many people know, I find the term "business architect" problematic. Does a business architect truly design the business? If so, does that start with ideation?
Or, is the business architect more of an assessor? Analyzing the current design to suggest, or apply changes?
Or, is the business architect more of a recorder (archivist)? Capturing the current, future and transitional design aspects for use in operations, measurement, analysis and change initiatives?
Or, yes one more, is the business architect the "matcher" of business and technology capability? Discovering new opportunities or solutions to hard problems?
I know, "it depends". Thus, my problem with the term. The activities described above vary from high-level strategy to information management. Each is important. But, are they all done by Business Architects? I’ll skip the "are they all business architecture activities" question for now.
Instead, I’ll return to this post’s title: Business Architect circa 1925. In his book, The Prize, The Epic Quest for Oil, Money and Power, Daniel Yergin recounts a 1925 conversation between Calouste Gulberkian and Walter Teagle on royalty compensation. During the exchange, Gulberkian takes offense at being called an "oil merchant":
"…Surely, Mr. Gulbenkian, you’re too good an oil merchant not to know that the property won’t stand any such rate as that."
"Gulbenkian’s face went red, and he furiously banged the table. "Young man! Young man!" he shouted. "Don’t you ever call me an oil merchant! I’m not an oil merchant and I’ll have you distinctly understand that!"
"Teagle was taken aback. "Well, Mr. Gulbenkian," he began again, "I apologize if I have offended you. I don’t know what to call you or how to classify you if you aren’t an oil merchant."
"I’ll tell you how I classify myself," the Armenian replied hotly. "I classify myself as a business architect. I design this company and that company. I designed this Turkish Petroleum Company and I made room for Deterding and I made a room for the French and I made a room for you." His fury was unabated. "Now, the three for you are trying to throw me out on my ass."
If Gulbenkian worked in your organization today, would he — the business designer — be right in his fury? Or, would he be an oil merchant, who is assisted by business architects, who record, analyze and/or help execute his design?
Me, I’m with Gulbenkian. Table pounding and all.
