Wednesday, January 25, 2006

A Culture of Innovation? Or NOT?

By any measure, IBM is a huge corporation. With around 300,000 employees there is a large number of really smart people covering almost any field of business or technology. As a result we inside IBM suffer from information overload. There are thousands of “communities of practice”, “centers of excellence”, and “knowledge management teams” that regularly publish zillions of pages of information in internal newsletters, intranet pages, and internal blogs,. There is simply not enough time to go through it all.

To cope, most of us who are drowning in information settle on a few sources of information that make to our “short list” of favorite sources. My post tonight comes from one on my personal “short list.”

Every so often I get an internal newsletter entitled “Consultant’s Edge” put out by Peter Andrews of our Executive Business Institute. (Regular readers of this blog may remember a previous post based on his work called “Crisis in Time, Talent, Trust and Transformation.”) I find Peter states business issues in just such a way that it makes sense to my architect brain quickly and helps me figure out how to communicate with that all important “business side” of the house.

The last “Consultant’s Edge” had to do with corporate culture as it relates to innovation. With his permission (Thanks Peter!), I would like to share a diagnostic quiz he developed to help executives assess how their company innovates (or doesn’t innovate). I think any good I/T Architect can see the wisdom in this diagnostic immediately. You’ll see your business users, customers, and clients in almost every word.

Defining innovation within an organization

For the first set of questions below, you may mark down as many answers as apply, writing down A, B, C, D and/or E. At the end, count up how many of each letter you have recorded for questions 1 through 6.

Question 1: What is the perspective of your organization on innovation?

A. Innovation needs to make a return-on-investment contribution this quarter

B. Innovation should continually and reliably improve our offerings and follow a known, accepted process

C. Our innovations include adopting the best ideas in our industry

D. We believe in getting our innovations from everywhere, even if it means we must adapt and re-envision them from other industries

E. Innovation from us should catch everyone with surprise and should occasionally disrupt competitors

It’s not unusual to be able to poke into the corners of your organization and find people who hold all of these perspectives. That’s fine, but generalize which style fits best. The second question is a bit more challenging because it goes from belief to action – specifically, measurement.

Question 2: How do you measure innovation?

A. Innovation proves itself quarterly with standard business measures related to profits, growth and market share

B. Our innovations start from a solid business case, and then must achieve standard milestones along the formal innovation process

C. We measure our innovation by comparing ourselves with the best in our industry

D. In addition to maintaining a solid track record over the years of contributions to the business through innovation, we use specific measures of how we are viewed by the public and the media vs. other innovative organizations

E. We look at our stock price, the requests from others for advice on how to innovate, who wants to partner with us and whom we have disrupted with our innovations

Let’s push things a bit further and look at the results of your activities. Let’s look at the innovations themselves.

Question 3: What do successful innovations for you actually look like?

A. The project gets done on time and delivers the business results we committed to

B. Our offerings are constantly being improved

C. We are quickly able to match any innovations by our competition

D. We have our share of important “firsts” in the marketplace

E. We change how success is measured in our marketplace and our innovations make us the unqualified leaders

Now we’ll shift to an outside perspective, one of the most important ones.

Question 4: What do investors expect of your organization?

A. Our investors expect steady performance, but do not expect much, if any, growth

B. Our investors expect us to fulfill our plans and to grow as well as our market

C. Our investors push us for growth, and we sometimes please them

D. Our investors are focused on our steady growth and improving market share

E. We offer our investors lots of sizzle, backed up by dramatic successes


Now, some of those questions touch indirectly on the investors’ view. That’s intentional. In general, investors looking for achievement do not like you to take too many risks with their money. More and more, they want you to perform within a time period that really puts the pressure on, like the next quarter. But with the right story and a good history, they’ll accept, and maybe even welcome, a longer view. Of course, that view needs to be balanced against what your competitors are up to, which brings us to our next question.

Question 5: In the context of innovation, how would you describe your relationship with competitors?

A. Competitors often throw us off balance, force us to change our plans and sometimes make us miss our financial targets

B. Our competitors often beat us to market and take share

C. Our competitors respect us and know we can match them in most instances

D. Our competitors follow our moves closely and are frequently forced to follow where we lead

E. Often, organizations are dismayed to discover we are their competitors

When we talk about competitors, it’s tough to give an honest answer. We are doing a quick diagnostic here, but you’ll need to move to real business intelligence and a good set of measures to get a more quantifiable view of where you stand versus competitors. Our last question is one that pulls together the others, in a way. But it’s worth asking.

Question 6: What is your organization’s reputation as an innovator?

A. Our organization is thought of as dependable and reliable, but not exciting

B. Our organization is important within its marketplace, but not looked to for trends

C. We are considered to be a competent organization that validates new trends

D. Our organization is looked to for leadership

E. We are lethal to competitors, great to partner with, and people never know what we are going to do next

Really looking at the content of each question and discussing it with your team should lead to some insights and maybe even a sense of the opportunities before you. In the meantime, count up how many of each letter you put down. Each of them point to a specific kind of innovation that has credence within the enterprise you are taking a look at. Here are the kinds of innovation that inspired the questions:

A. Innovation is changing something for the better within our organization

B. Innovation is making incremental improvements within our products and services

C. Innovation is adopting the best practices for our marketplace

D. Innovation is doing something that is new to our market

E. Innovation is breaking into or disrupting marketplaces

If you have three or more A’s, the first kind of innovation is probably happening. If you have three or more B’s, innovation includes incremental improvements to products and services. And so on. You may have all five of these kinds of innovation going on within the organization you’re looking at. Or only one. What you should have depends on your market, your strategy and your real-world business situation. The important thing is to get a more realistic view of what is actually going on and to make sure this is broadly understood.

Identifying existing innovation capabilities

No matter what innovation means, it can only be successful if the capabilities to support it are available. In general, the more challenging the innovation is and the broader the portfolio of innovation efforts, the more capabilities you’ll need. Here is another set of questions to get a start at both assessing and thinking about innovation capabilities.

Innovations are done by people, so that’s the starting point. For questions 7 through 11, record your answers using the numbers 1, 2, 3, 4 and/or 5.

Question 7: What kind of people does your organization have?

1. Our people know their roles and generally execute with experience and competence

2. Our people are great at doing analysis on new projects, then making sure they stay with the plan and achieve expected results

3. Our people work out the details, but are willing to make corrections mid-project and to take on some uncertainty

4. Our people work on a variety of low and high risk projects, but they all include those who are willing to try new things and push the limits

5. Our people are always looking for the big opportunity and everyone (even our clients) is an innovator

And innovations are never done in a vacuum. They are always tied to real world needs and possibilities.


Question 8: How does your organization detect opportunities for innovation?

1. We watch to see how competitors are getting business value

2. We listen to our customers and pay attention to the ideas our innovators have for which a good business case can be built

3. We scan our industry annually for best practices

4. We look far and wide for good ideas and are particularly driven by innovation successes that are related to our capabilities and our market, even if they come from another industry

5. We not only want the best we can come up with, we want the best innovations possible, so we provide forums for ideas and opportunities for action that include our people, our clients, researchers, suppliers and even competitors

But it’s not just about the payoff. Every innovation effort must be considered against the possibility of failure.

Question 9: How do you view the risk presented by innovation?

1. We manage risk by limiting activities and punishing failure

2. Adherence to our process limits our risk, as does the careful monitoring of milestone achievement

3. We are comfortable with a limited range of risks for different kinds of innovation projects, but look for a record of proven benefits

4. We always include high risk (but high potential) projects among several options in a managed portfolio of innovation efforts because our leadership understands the value of leading our market

5. If the possible benefits are high enough, we’ll bet the company

The ultimate reality check on capabilities in a business is funding. Where does the money come from and how reliable is it? Funding is an action that speaks much louder than any vision statement.

Question 10: How do you fund innovation?

1. Every innovation project must compete with all other projects and show higher value in our budgeting process

2. We have an annual process where research and development organizations get a set percent, then allocate according to our roadmap and commitments

3. We always ensure that some of our funding goes to strategic projects aimed at our maintaining our leadership position

4. Funding for each project depends on the criteria established for its place in the portfolio, and we continually rebalance our portfolio of innovation efforts to maintain an aggressive posture

5. We dedicate all the resources that are needed to ensure the success of our high-impact innovation projects

Finally, there needs to be a process for getting the innovation done. And for any broad portfolio facing dynamic situations, there may need to be many processes.

Question 11: How does innovation get done in your organization?

1. We identify the innovation and manage the same way we would any other important program

2. We have a standard process in place to identify opportunities for improvement, select them, develop them and introduce them to our offerings

3. We have more than one formal way to bring innovation ideas forward and make them happen, depending on the goals

4. Our innovations have been realized through a variety of pathways, both informal and formal

5. We provide time and resources to actively encourage our people to get new things started, then provide opportunities for them to move things along informally before they are finally introduced into formal pathways

That completes a quick and dirty gap analysis of the capabilities available for the innovations to which organizations aspire. Below, the dots between the two are connected, and some labels are provided for the specific capabilities implied by the questions.

A. Innovation is changing something for the better within our organization – so you need “1’s”: Project management, measurement, relevant skill/talent and leadership

B. Innovation is making incremental improvements in my products and services – so you need “2’s”: Planning, defined development process and technology transfer

C. Innovation is adopting the best practices for our marketplace – so you need “3’s”: Business intelligence, strategy, integration and a flexible business model

D. Innovation is doing something that is new to our market – so you need “4’s”: Risk management, research and portfolio management

E. Innovation is disrupting my marketplace – so you need “5’s”: Creativity, communities and informal processes

Evaluating the innovation climate: Motivating people

Developing or obtaining these capabilities is hard work and requires the focused and coordinated efforts of management. This work is necessary, but not sufficient. Even with all the capabilities in place, there still needs to be a good climate for innovation – specifically for the innovations that are desired. Five final questions provide a quick check on the current climate.

Again, innovation begins with people and what they need to be motivated. For questions 12 through 16, record your answers using the lowercase letters a, b, c, d and/or e.

Question 12: What rewards does your organization provide for innovation?

a. Everyone in our organization can name an innovator who left or was pushed out

b. Those who successfully improve our offerings are given bonuses on an annual basis

c. We reward inventors with new patents and those who help us implement new, strategic projects successfully

d. We have a variety of rewards at many levels for those who invent, discover new possibilities, adapt innovations to new situations, nobly fail and help their teams achieve milestones that are appropriate for the kinds of projects they are working on

e. Our organization shares the successes and learns from failures, but we create millionaires every year

The innovators need to be able to team together, often across the organization.

Question 13: How would you describe the status of informal networks and processes in your organization?

a. We don’t discourage camaraderie, especially during holidays, but going outside our established areas or processes is frowned upon

b. We expect people’s primary allegiance to be to their teams and we have good formal process for them to get their work done

c. We are encourage informal communications by moving people into different business units so they can build their networks

d. We always make sure there is some extra time and opportunity for experimentation, and our people have communities of practice and some opportunities specifically designed to encourage cross-organizational conversations

e. Informal communities are where most of our key innovations get their start and we have lots of routes – both formal and informal – to get new projects off the ground

Question 14: How does your organization respond to change?

a. We are reluctant to change, do so slowly and only with difficulty

b. Since most of our changes are introduced gradually, through a well-recognized process, we have little difficulty

c. We have one or more big changes each year and we rely on change management techniques (e.g., leadership, communications) to get us through

d. Our changes are not entirely predictable so we work aggressively at getting the right people involved and devoting resources to manage change

e. We depend on each person in our organization to be ready for change, and this is supported by a great track record in leading change and benefiting as an organization from successful change

Question 15: How would you describe the culture of your organization?

a. We have established processes and rules and our people shouldn’t violate them

b. People know what is expected of them and they collaborate well across the organization through familiar interlock processes

c. We can move people to other business units for projects without major disruptions; competence is celebrated

d. Our people are primarily dedicated to the success of the whole organization, rather than their business units, and we have matrix management and formal communities to help support that

e. We look messy and have lots of tough discussions across the organization, but we have basic belief, a common vision and strong, organic communities that keep us working together.


Question 16: What kind of customers does your organization have?

a. Our customers are low growth, so they mainly push for cost savings

b. Our customers are successful, but they don’t include the industry leaders

c. Our customers expect us to be as good as our competitors and to provide dependable roadmaps for adoption of any new technologies

d. Our customers include a significant number who look to partner with us to do things that are new to our industries

e. Our customers are also our partners and they have high expectations that we will create the next generation of offerings


These last five questions help you do a simple analysis of the readiness of your climate for innovation:

A. Innovation is changing something for the better in my organization – so you need “a’s”: Adherence to processes, focus on results and clear rules

B. Innovation is making incremental improvements in my products and services – so you need “b’s”: Well-defined roles, attention to deadlines, evaluations that are complete and fair and an emphasis on working well within your team

C. Innovation is adopting the best practices for my marketplace – so you need “c’s”: Enthusiasm for change, opportunities for working across the organization, rewards for adaptiveness

D. Innovation is doing something that is new to my market – so you need “d’s”: Tolerance of risk, flexibility, open communications with clients and suppliers, rewards for inventiveness

E. Innovation is disrupting my marketplace – so you need “e’s”: Celebration of rebels and honest failures, rewards for many roles, appreciation of talent, vibrant informal communities

It would not be fair to pigeonhole any one company into any of these styles. However, since organizations are largely driven by their marketplace, some industries are more prone to one model versus another.

Just to help you map the innovation culture styles:

A’s – Regulated utilities may be appropriate

B’s – Airlines may be a good example here. They often try to lead or quickly follow changes in the marketplaces. However, some are more successful and there are clear leaders and followers

C’s – There are a wide spectrum of auto companies but a few obvious industry leader fit into this style

D’s – High tech’s typically fit here and a few leading consumer oriented firms jump to mind as they continually lead and re-invent themselves

E’s – Very few organizations fit here and it would only be unfair to point out leaders like Google (but you already discovered that yourself by taking the quiz)

Going from intent to outcome is never easy. Aligning the climate of your organization to enable innovation is difficult and may take time. Culture is notoriously difficult for organizations to change.

The questions above, however, provide a first step toward understanding what your organization really expects from innovation. And, discovering the gaps – between what the relevant capabilities and climate are and what each needs to be – can be a key step toward the required outcomes.

I must admit that after reading this the first time I wondered what my own level of innovation was. How would I fit in at some small startup? How would I fit in at a "disruptive" company like Google? Is IBM considered "disruptive" to its competitors because of its innovation? or just is size (read $$$). Comments are welcome and encouraged.

Please check out the “Future Value” class that Peter Andrews teaches for additional information and more of his business insight! Check it out so he'll continue to let me "borrow" his stuff for my blog!

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Tuesday, January 24, 2006

ESB Patterns that "Click"

One of the highlights of my trip to IBM Software University 2006 in Las Vegas last week was a session led by Marc-Thomas Schmidt, IBM Distinguished Engineer and Chief Architect WebSphere Enterprise Service Bus. He presented some architectural patterns which just “clicked” with me and I hope will “click” with any of my readers who might also be digging into Service Oriented Architectures (SOA) and the concepts behind an Enterprise Service Bus (ESB) in particular. With his permission, I will share some of the concepts he presented with you. Click on the embedded graphics to get a larger, more readable view.

What is an ESB
With an ESB, rather than interacting directly, participants in a service interaction communicate through a bus that provides virtualization and management features that implement and extend the core definition of SOA. The ESB provides virtualization of:

  • Location and Identity – participants need not know the location or identity of other participants, e.g., requesters need not be aware that a request could be serviced by any of several providers; service providers can be added or removed without disruption.

  • Interaction protocol or style – participants need not share the same communication protocol or interaction style; a request expressed as SOAP/HTTP may be serviced by a provider that only understands Java Remote Method Invocation (RMI). Interaction partners may chose to use one-way, request/response, asynchronous, synchronous, and publish/subscribe type interactions

  • Interface – requesters and providers need not agree on common interface. The ESB reconciles differences by transforming request messages into a form expected by the provider.

  • Qualities of (Interaction) Service (QoS) – participants declare their QoS requirements through policies which include, for example: performance and reliability, encryption of message contents, routing algorithms (e.g. to available implementations, based on workload distribution criteria, and so forth). Policies that describe the QoS requirements and capabilities of requesters and providers may be fulfilled by the services themselves or by the ESB compensating for mismatches.






As depicted in the left hand part of the picture, messages flow over a bus that interconnects a variety of communicating participants. Some participants invoke services offered by others; other participants publish information to interested consumers.

Interposing the bus between participants provides the opportunity to modulate their interaction through a logical construct called a mediation. Mediations operate on messages in-flight between requesters and providers.

The basic ESB pattern abstracts application components into a set of services that interact via a bus rather than through direct, point-to-point communications. A given service can be a provider, a requester, or both. The ESB provides interaction points where services put messages on the bus, or take them off. It applies mediations to messages in flight and guarantees QoS to these managed interactions.

Patterns for building ESB-based solutions are classified as: interaction patterns to enable service interaction points to dispatch messages to or receive messages from the bus, mediation patterns to enable the manipulation of message exchanges, and deployment patterns to support solution deployment into a federated infrastructure.

Interaction patterns

The ESB enables endpoints to interact in their native interaction mode via the bus. It supports a variety of endpoint protocols and interaction styles. A few examples of interaction patterns include request / response, request / multi-response or event propagation:








Mediation patterns
Mediation patterns manipulate messages in flight on the bus (requests or events). Messages dispatched by a requester are transformed into messages understood by a semantically matching but structurally incompatible provider selected from a set of potential endpoints.









Complex patterns
Mediation and interaction patterns can be combined to realize more complex patterns.
For example, a protocol switch followed by a transformation can implement the Canonical Adapter pattern in which the set of messages and business objects used by all parties is normalized to a canonical format.




Deployment patterns
Solution Administrators have several choices for ESB topologies. Some common examples are shown below.
  • Global ESB: all services share one namespace and each service provider is visible to every service requester across a heterogeneous, centrally-administered, geographically distributed environment. Used by departments or small enterprises, where all the services are likely to be applicable throughout the organisation.

  • Directly Connected ESB: a common service registry makes all of the services in several independent ESB installations visible. Used where services are provided and managed by a line of business but made available enterprise-wide.

  • Brokered ESB: bridge services that selectively expose requesters or providers to partners in other domains regulate sharing among multiple ESB installations that each manages its own namespace. Service interactions between ESBs are facilitated via a common broker that implements the bridge services. Used by departments which develop and manage their own services, but share a few of them, or selectively access services provided across the enterprise.

  • Federated ESB: one "master" ESB to which several "dependent" ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB to access services throughout the network. Used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.






I throw in some additional graphics which seem to resonate with me (forgive me for not explaining them all in great detail) but I'll ask you to probe further at an article co-authored by Marc: SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus.











Monday, January 23, 2006

High Points and Challenges Regarding SOA and Other Tidbits from IBM Software University

The “Best Stuff” from IBM Software University 2006 (in my humble opinion)

IBM Software Group I/T Architects were almost giddy with delight about IBM’s acquisition of DataPower, a manufacture of Enterprise Service Bus (ESB) “appliances” used to “speed and secure” Service Oriented Architectures (SOA). There was much buzz about how this “ESB in a box” would be a great way to put ESB technology and web services gateway technology in particular in corporate DMZ’s. I think it is a great convenience also for smaller companies interested in a plug in device vs. managing a software stack on a traditional server.

Some great ESB pattern work I’ll cover in a future post. (link to left added after the fact when new post added)

Service Component Architecture (SCA) and how it is used to assemble services into composite applications.

A good discussion of “Simplicity” in our solutions vs. being “Simplistic”.

The Architect “Jam” with the top Software Architects from the IBM Architect Software Board, DB2, WebSphere, Tivoli, Lotus, and Rational.

New collaboration between the IBM Software Group labs and field practitioners.

IBM acquisition of PureEdge and the incorporation of this technology for e-Forms into IBM Workplace Forms. This offers great technology to get closer to the “paperless office” environment and eliminate the need for optical character recognition (OCR) of paper forms and faxes.

On the methodology front, a plug in for the Rational Unified Process (RUP) to support SOA projects.

New research from MIT showing correlation between the business agility provided by I/T investments and business value generated.

IBM acquisition of BowStreet technology and its use in “dashboard” type displays in portal applications.

Improvements in packaging that allows WebSphere Process Server version 6.0.1 to be installed from a single CD and have all the components required to run sample Business Process Execution Language (BPEL) process flows.

Improvements in the new WebSphere Business Modeler to include a swim lane editor and a business measures editor.
SOA Challenges Still Out There (also my humble opinion)
Governance of SOA in the budget and political realities of our customers. This includes a lack of shared funding models for shared services. (See my previous post on the funding topic)

Relative complexity of the software stack required to implement a full-featured SOA within a corporation including ESB, identity management, security, service aggregation, process choreography, etc.

Semantic interoperability between web services in large organization. “Does a purchase order service mean the same thing to me as it does to you?” This is closely related to the governance issue above. "How do we keep from proliferating a large number of similar but slightly different web services?"

Favorite Joke Heard:

"Do you know the difference between a computer salesman and a car salesman?.... The car salesman knows when he's lieing."

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Incredible Web Services Performance Achieved


I ran into a co-worker I had not seen in a while last week at IBM Software University 2006. He has a major US Bank as his customer. He told me how they were pushing the envelope of web services performance by running the WebSphere software stack on their mainframe using multiple (I think it was 13 of them) zSeries Application Assist Processors (zAAP) for the mainframe Java virtual machines. They just ran a performance test for a web service enabled IMS legacy system transaction. (SOAP messages over HTTPS in through the web/java/JCA/IMS layer and back) The workload was driven by the WebSphere Workload Simulator, recently renamed the Rational Performance Tester for zOS. The ran 1000 transactions per second while achieving a 0.1 second average response time. Granted, the bank does not have this in production but this sounds like a big step forward in web services performance to me.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Saturday, January 21, 2006

Password Protected Toothbrush


Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months.

Clifford Stoll







The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Thursday, January 19, 2006

Real World RFID Application in Production Now

Last year at Software University, IBM used bar code scanners at each training session as a way of taking attendance. As we entered each classroom, we would have to let someone shot an optical scanner at the bar code printed on the badge we had to wear around our necks. While I suppose a manager who suspected an employee of spending all day in the casino and skipping class could have eventually found out how many classes the employee's badge was scanned at, I think the real purpose was to track which classes and which types of classes were most popular. It was also a way to compare pre-registration attendance with the number of people who actually showed up.

This year, there were no optical scanners at the classrooms. Instead, we were each issued a name tag like badge we were to wear around our neck. Behind each name tag was an RFID. IBM hired a subcontractor to errect RFID receivers at doorways. Entrances to classrooms, the Solution Village, and the dining areas. Dining areas were not part of last year's optical scanning so I suppose this gathered data on how many people rushed to eat immediately after class and how many trickled in later after taking phone calls and checking email.

RFID at the breakfast dining area at the MGM Grand. I guess this is a way to answer how many people got up to eat vs. how many were out too late gambling the night before. This would be useful I suppose for planning how many meals to buy next year.


If you peal of the name tag to expose the RFID chip and antenna, this is what it looks like.




This is a zoom on the RFID chip and the connection to the antenna elements.




A close up of the antenna used at entrances.


RFID receiving antennas were also hidden inside these lighted signs at the entrances.


RFID antennas were also at the entrance to each class or event where employees were supposed to pre-register.



Copyright © 2005 by Philip Hartman - All Rights Reserved


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

IBM Software University 2006 in Pictures

I've been staying at the MGM Grand. Here's the view out my hotel window (taken through the glass) at about 6:30 am this morning. That's the New York New York Casino across the way.




Here's another angle showing the Tropicana, Excalibur, Mandalay Bay, etc.




One of several entrances to Software University.


Lunch with 10,000 of my closest friends from Software Group.


The Solution Village where all of IBM's brands and business partners are available for discussion, demos, product literature, etc.




A minor diversion... inside the Canal Shops area of the Venetian Hotel and Casino.



Got to leave tomorrow...

Copyright © 2005 by Philip Hartman - All Rights Reserved


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Exhilarating, Humbling, and Invigorating - IBM Software University 2006 in Las Vegas - Day 3

Being here in Las Vegas with my 10,000 closest IBM Software Group friends has been exhilarating, humbling, and invigorating.

It has been exhilarating because there have been so many opportunities to learn. I believe in the opening session they stated that there were over 3200 individual sessions to choose from. Granted, not all of them really apply to me as an I/T Architect but the sheer number of choices is staggering. (Warning-Radical Honesty to follow!) I might as well admit it, I also enjoy the opportunity to hear the insights and opinions of people who are influential. Tuesday, I got to sit in on an assembly of arguably the most influential software architects in the world. How many people can say that sat in a room with the head of the IBM Software Architecture Board and the top technical guru of each of the IBM software brands and the leader of our Business Consulting Services SOA team?... and to hear each of their opinions about the issues surrounding Service Oriented Architectures? How often do I get to hear the Chief Architect of the WebSphere Enterprise Service Bus product? I’m glad my management decided to be one of the 300 who got to join this party.

It was humbling because the exhilaration described above came at the price of realizing how much I don’t know and how many really cool and influential projects are going on. My projects are important in their own way but... truth be told... in my work I stand upon the shoulders of giants.

I must be a high-touch type person because I have found the face-to-face interactions here invigorating. In the consulting business in IBM these days we don’t get to have much time to meet face-to-face with our own internal management or other members of our consulting practice who are working with different clients from our own. We get to know our clients a whole lot better than the IBMers. This week has been a nice change, however. Tuesday, I had breakfast a Software Group Vice President in our WebSphere brand. I ran into an IBM Distinguished Engineer on the shuttle bus yesterday. I had breakfast today with a Business Consulting Services Partner and Associate Partner in the Retail Industry. Today for lunch I got to talk with the Enterprise Application Development Practice Leaders for the SouthEast, Central, and West regions. We had a spirited discussion on how the changes in our consulting business are affecting the careers of our technical practitioners (I/T Specialists and I/T Architects). I renewed an acquaintance with the architect who heads our Rational brand product skills enablement. I got to talk to the architect who is building some tooling around some of our design patterns and best practices. One of my official mentors and I got to meet face-to-face for the first time after talking on the phone for about a year. I ran into an old friend who is now the lead IBM Architect supporting on of the 10 largest banks in the US. One my current interests is application development around the business problem of product warranty. I got to eat dinner tonight with a BCS Partner knowledgeable in this area . This is all goodness and not easily reproducible in the “distance learning” favored by corporate bean counters.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Monday, January 16, 2006

Greetings from Software University in Las Vegas

In this era of constant corporate pressure to cut costs, it has been my good fortune to have been selected as one of a handful of IBM Global Services people to tag along with 10,000 of my closest friends from IBM Software Group to the training event IBM Software University 2006 in Las Vegas, Nevada.  The window from my hotel room in the MGM Grand looks out across the Las Vegas Strip at the New York New York, Excalibur, Tropicana, and Mandalay Bay casino hotels.  I have an obstructed view of the Luxor pyramid and the top few floors of Monte Carlo as well.

The opening session for all 10,000 of us included some door prizes (Unfortunately, I did not win the iPod Nano.), some high-tech entertainment, a talk by Steve Mills, more talk by Mike Borman, and an inspirational speaker/mountain climber/explorer named Jamie Clarke.  If you detected a correlation between the trials and tribulations of scaling Mount Everest and the trials and tribulations of taking on the competition everyday in the software industry, you were dead on.  Jamie Clarke was great and I’d recommend him to speak at any corporate event.

I have one more huge session in just a half an hour that includes all of us here from the Americas.  However, the rest of my week will be spent with my I/T architect peers.  The primary topic is likely to be service oriented architectures (SOA) and all the issues associated with making it a reality in world of our clients.  I look forward to the interaction with old colleagues and for the chance to make new acquaintances with like interests.  It should be a great week!

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Thursday, January 12, 2006

Doubts

The greater the artist, the greater the doubt. Perfect confidence is granted to the less talented as a consolation prize.

Unknown

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Monday, January 09, 2006

I've Been Promoted to Chief Process Officer

I stumbled across some interesting reading in the blogsphere recently related to business process management (BPM) and the associated culture changes which seem to trump any technology issues. Take Phil Gilbert’s blog Perspectives in Process . He has an article “
Is it Time for a Chief Process Officer?” where he makes a few interesting points.

“These factors combine to mean that the complexity of running your business is
way up, even as the old costs of doing what you do are going way down. It's less
costly - on a direct basis - to build something in China and ship it here than
it is to build it here. But guess what, it's a lot more complicated. And if you
don't get a grip on these new complications, you will eat up in costs and in bad
service everything you wanted to save!

Process, then, is the word we use
today to describe "getting a handle on the complexity, putting programs in place
to reduce the complexity, and scaling our ability to consume the supply chain
and deliver to the channel in as easy a way as possible." The companies that are
able to do this - scale the integration and complexity - will win.
....
Because of this, "process" becomes the business. A business is no
longer defined by its goods and services as much as it is defined by its
capabilities. Is Wal-Mart in the, um, what business is Wal-Mart in? What do you
call a business that provides retail hard goods, medical services and banking?
In the end, the products don't define Wal-Mart as much as their capabilities
define them.
....

So now, back to the original question: Is it time
for the CPO? Absolutely. The only other person who is capable of leading such a
shift (or who should be tasked with leading such a shift) is the CEO. So if the
CEO isn't ready to take this on, then some, one person should be designated as
the person to move the company's capabilities into the limelight.”


Another interesting read is in James McGovern’s blog called Enterprise Architecture: Thought Leadership He has an article “Recent Thoughts on BPM” in which he takes a few shots at Phil Gilbert’s notion of a Chief Process Officer and asks why he is

encouraging yet another ivory tower role be created
within the enterprise. Curious if he doesn't think that this is already covered
by folks who practice real enterprise architecture? If I were a vendor though, I
too would encourage creation of such a role as it makes it a lot easier for me
to identify whom to sell to...”

Incidentally, if you don’t like James McGovern’s ideas on Enterprise
Architecture, you may be amused by the assortment of completely unrelated
photographs and political cartoons mixed in with all the architecture
discussion. Conservatives beware, most of his political commentary in the margins is often on the liberal side... but his blog is never boring.


Phil Gilbert responded to some of McGovern’s points in a second blog article “A Chief Process Officer.” In it, he distinguishes he idea from an “ivory tower” position as follows:

”The single biggest reason process-centric projects fail today is bad
governance. Processes span functions and when optimizing a given process,
political disputes arise, and there's no single owner that has the power to
drive the project to completion. Something that is good for the organization is,
basically, killed because someone's power would have been
diminished. The answer is not another reorg! The answer is to drive a
process-based culture, but in the short-term (read: the real world) what this
means is that someone will need the power to make this stuff happen. You can't
change culture without changing reality. I propose that this means - in
practical terms, not in "ivory tower" terms - someone with clout has to be
driving the process initiative.”

All this talk reminds me of previous post on my blog, “The Role of the Business Transformation Architect” in which I quote a colleague of mine Douglas McDavid, a member of the IBM Academy of Technology. Is a Business Transformation Architect basically a Chief Process Officer with political clout?

Oh, I was just kidding about getting promoted.... but I'd take it if they gave it to me.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Friday, January 06, 2006

More Fun With License Agreements and SOA

How many of us I/T Architects actually read and care about all that legal jargon associated with software license agreements? How many times have you just clicked “Yes, I Accept” without really reading what you agreed to? I know I'm guilty and I expect 98% of you are too.

We all may have to start calling our friendly neighborhood intellectual poperty (IP) attorney. Check out Chris Lindquist’s blog TechLinkLetter on the CIO.com website and his article “GPL 3.0: Open Source Renews Its License” too see how rumored changes in GPL 3.0 might impact anyone using open source software in a Service Oriented Architecture (SOA) environment. Here are a few quotes:

“Second, and potentially much more challenging, is the possibility that GPL 3 will impose its licensing conditions on GPL-based software that is not physically distributed, but is exercised by remote execution. Specifically, the rumor is that the redistribution requirements will be imposed on GPL software used as part of a “Software as a Service” implementation. This means, for example, if an application service provider uses modified GPL code in its product, it would have to make the modified code available free to the public.

And remember that “viral” thing? That means if the modified GPL code is commingled with the ASP’s proprietary code, the whole thing could potentially becomes GPL. There’s no doubt that some software-as-a-service vendors will get caught up in this license requirement, should it come to pass.

And there’s another organization that could get tangled: yours. If you are one of the many IT organizations moving to service-oriented architectures (SOA), you are delivering software as a service. If part of your software stack is GPL, any changes to the license could affect your obligation to release your source code publically.”

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Wednesday, January 04, 2006

Skewering of the Semantic Web

See Clay Shirky's article, "The Semantic Web, Syllogism, and Worldview" for a real skewering of the Semantic Web initiative. Some quotes:

The Semantic Web's Proposed Uses #


Dodgson's syllogisms actually demonstrate the limitations of the form, a pattern that could be called "proof of no concept", where the absurdity of an illustrative example undermines the point being made. So it is with the Semantic Web. Consider the following, from the W3C's own site:


Q: How do you buy a book over the Semantic Web? A: You browse/query until you find a suitable offer to sell the book you want. You add information to the Semantic Web saying that you accept the offer and giving details (your name, shipping address, credit card information, etc). Of course you add it (1) with access control so only you and seller can see it, and (2) you store it in a place where the seller can easily get it, perhaps the seller's own server, (3) you notify the seller about it. You wait or query for confirmation that the seller has received your acceptance, and perhaps (later) for shipping information, etc. [http://www.w3.org/2002/03/semweb/]


One doubts Jeff Bezos is losing sleep.


This example sets the pattern for descriptions of the Semantic Web. First, take some well-known problem. Next, misconstrue it so that the hard part is made to seem trivial and the trivial part hard. Finally, congratulate yourself for solving the trivial part.


All the actual complexities of matching readers with books are waved away in the first sentence: "You browse/query until you find a suitable offer to sell the book you want." Who knew it was so simple? Meanwhile, the trivial operation of paying for it gets a lavish description designed to obscure the fact that once you've found a book for sale, using a credit card is a pretty obvious next move. (boldface mine)

....



From time to time, proselytizers of the Semantic Web try to give it a human face: For example, we may want to prove that Joe loves Mary. The way that we came across the information is that we found two documents on a trusted site, one of which said that ":Joe :loves :MJS", and another of which said that ":MJS daml:equivalentTo :Mary". We also got the checksums of the files in person from the maintainer of the site.

To check this information, we can list the checksums in a local file, and then set up some FOPL rules that say "if file 'a' contains the information Joe loves mary and has the checksum md5:0qrhf8q3hfh, then record SuccessA", "if file 'b' contains the information MJS is equivalent to Mary, and has the checksum md5:0892t925h, then record SuccessB", and "if SuccessA and SuccessB, then Joe loves Mary". [http://infomesh.net/2001/swintro/]


You may want to read that second paragraph again, to savor its delicious mix of minutia and cluelessness.


Anyone who has ever been 15 years old knows that protestations of love, checksummed or no, are not to be taken at face value. And even if we wanted to take love out of this example, what would we replace it with? The universe of assertions that Joe might make about Mary is large, but the subset of those assertions that are universally interpretable and uncomplicated is tiny.

...

Meta-data is Not A Panacea #


The Semantic Web runs on meta-data, and much meta-data is untrustworthy, for a variety of reasons that are not amenable to easy solution. (See for example Doctorow, Pilgrim, Shirky.) Though at least some of this problem comes from people trying to game the system, the far larger problem is that even when people publish meta-data that they believe to be correct, we still run into trouble.


Consider the following assertions:

  • Count Dracula is a Vampire
  • Count Dracula lives in Transylvania
  • Transylvania is a region of Romania
  • Vampires are not real


You can draw only one non-clashing conclusion from such a set of assertions -- Romania isn't real. That's wrong, of course, but the wrongness is nowhere reflected in these statements.


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.