elemental links

brenda michelson's technology advisory practice

business-first technology leadership wins

By

In 2010, when I wrote the Elemental Links tagline, “Technology Insights for Business Enthusiasts”, some of my trusted associates pushed back, telling me that I need to lead with TECHNOLOGY. But, here’s the thing. In the enterprise, from which I came and continue to serve, a technology-first mindset leads to disdain.

Contrary to the hyperbole of the technology press, analysts, pundits and product marketers, true, enduring, information technology success begins with a business-first mindset, which includes constant context checks.

Now, it would be fair to slap a (micro) pundit label on me, so what follows are snippets from three business-first technology executives, excerpted from this week’s WSJ:

“What directors really value in a CIO is sound strategic thinking and a great ability to execute, says Gambale, a former CIO at Merrill Lynch, Bankers Trust, and Alex Brown, and former partner at Deutsche Bank Capital.”

via Art Langer: Virginia Gambale Says CIOs Should Offer Strategic Advice to Corporate Directors – The CIO Report – WSJ.

“We never start with technologies; we always look at trends in the world that are or may be having an impact on the future of our business. One example is the acceleration of innovation to market. Consumers and users want one-on-one connections to any service or product they interact with, so we have to respond. This is thoroughly changing the way we operate—the always-on, instant nature of interaction today.

We look at those megatrends and forces to see which ones will truly impact our business. Then we go look at what strategies we can devise to take advantage of those trends. The final step is evaluating which technologies can enable those strategies. The value is how we enable this dramatic change through technology.

Every three years or so, we review our strategies. Three years ago we focused on the idea of visualization. We have visualized data across the entire company. Everything we do is visual. This transforms the way the business performs because it creates what I call “information democracy.” There are no more layers. The discussions we are having are much more robust.”

— Filippo Passerini, president of global business services and CIO of Procter & Gamble in WSJ CIO Journal

“We’re truly guided by these big arcs of change [analytics, cloud computing, emerging markets and “smarter planet] that we believe in,” Rometty said. “They lend context and clarity. When you run a big company, context and clarity mean a lot.”

via New IBM CEO Says Will Maintain Longer-Term Strategy

Elinor Ostrom, Nobel Laureate, on Design Principles for Common Pool Resource Institutions

By

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:

  1. Clearly-defined boundaries: individuals or households who have rights to withdraw resource units from the CPR must be clearly defined, as must the boundaries of the CPR itself.
  2. Congruence between appropriation and provision rules and local conditions: Appropriation rules restricting time, place, technology and/or quantity of resource units are related to local conditions and to provision rules requiring labour, material and/or money.
  3. Collective-choice arrangements: Most individuals affected by the operational rules can participate in modifying the operational rules.
  4. Monitoring: Monitors, who actively audit CPR conditions and appropriate behaviour, are accountable to the appropriators or are the appropriators.
  5. Graduated Sanctions: Appropriators who violate operational rules are likely to be assessed graduated sanctions (depending on the seriousness/context of the offense) by other appropriators, by officials accountable to the appropriators, or both.
  6. Conflict-resolution mechanisms: Appropriators and their officials have rapid access to low-cost local arenas to resolve conflicts among appropriators or between appropriators and officials.
  7. Minimal recognition of rights to organize: The rights of appropriators to devise their own institutions are not challenged by external government authorities.

    For CPRs that are part of larger systems:

  8. Nested enterprises: Appropriation, provision, monitoring, enforcement, conflict resolution and governance activities are organized in multiple layers of nested enterprises.

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.

Forrester’s Empowered: Workplace HEROes + DIY Technology = Recipe for Shadow IT Disaster, or Front-Line Innovation?

By

Like many with corporate IT backgrounds, I find the do-it-yourself (DIY) technology movement simultaneously intriguing and frightening. Intriguing, because of the ease of connecting with co-workers, partners, customers and information to solve problems, improve interactions and advance the business.  Frightening, because I’ve lived through (barely) the data, network and integration nightmares brought on by islands of Access, Excel, FileMakerPro, Visual Basic, etc.

Of course, today’s DIY technologies – Smart mobile devices, Pervasive video, Cloud computing services and Social technologies – are exponentially more powerful than their office productivity predecessors.  Therefore, they must be exponentially more troublesome, right?  Well, that depends.

In Empowered, a new book by Josh Bernoff (co-author of Groundswell) and Ted Schadler of Forrester Research, the authors address this very challenge, how to balance front-line innovation with back-room risk management.  Or, as the authors describe it, changing the way your business runs to harness the power of HEROes: highly empowered and resourceful operatives. 

Following an attention grabbing introductory section, the book’s guidance is presented in two more parts.  In part two, the authors focus on HERO projects, describing opportunities and challenges, elucidating with real-world examples, sharing tools and walking through a four-step process to match-up with that other critical DIY base, your empowered customers.

A helpful tool is the HERO Project Effort-Value Evaluation.  After answering a series of questions on a potential projects effort and value, you calculate your projects EVE score.  Scores fall into one of six categories, from no-brainer (value exceeds effort by 25 points) to shadow IT (high effort).  On the Shadow IT projects, the authors don’t say never, however they point out the risk factors, success impediments, and advise collaboration with senior management and IT.

 

In part three, the authors discuss how management, information technology and HEROes work together to achieve that all important opportunity-risk balance.

The critical concept in part three is the establishment of a HERO Compact.  The HERO Compact is an accord between management, information technology and HEROes, guiding each group’s behavior to make “HERO-powered innovation successful”.

In the spirit of empowerment, I’ve clipped the high-level HERO Compact from Amazon’s Search Inside this Book. 

The chapter continues with specific pledges for IT, management and HEROes.  Each pledge reinforces that success requires individual responsibility, collaboration and trade-offs.

For example, the IT Pledge includes: “I will respect requests for new technology support and find ways to say, “Yes, and” rather than automatically saying “No.”. 

The HERO Pledge includes: “If my projects entail a significant effort, I will work with my managers and IT to better understand the long-term impact of those projects”.

And the Management Pledge includes: “I will respect assessments of technology risk in HERO projects and work with IT and others to quantify, mitigate and ultimately manage that risk”.

Empowered does a nice job of describing the compelling workforce and customer benefits of embracing DIY technologies, while painting a realistic view of the traps and risk, and offering pragmatic advice and tools for prospective HEROes, managers and IT to co-create a front-line innovation environment.

Organizations struggling to keep up with their customers, employees or competitors on the DIY technology revolution need to read Empowered and think seriously about HERO Compacts.

 

[Disclosure: Forrester sent me a free “no obligation” copy of Empowered.]

Business Architect, circa 1925

By

 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.

6+1 Secrets of Successful SOA

By

The deck from my Open Group Conference session, 6+1 Secrets of Successful SOA, is now on Slideshare.  The deck is a revision of the original 6 Secrets of Successful SOA talk delivered in May at ATA/ITLC.  If you’ve seen the original deck, jump to slide 24 for the +1.

6+1 Secrets of Successful SOA

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

Recent Posts

Recent Tweets