Integrated Infrastructure Blog

CIO as an Architect of the Business

John Soat wrote a summary of one of the panel discussions at the MIT Sloan CIO Symposium.  One of the interesting questions raised was whether the CIO should move from being a architect of the company's technology to being an architect of its business processes.  The response was "I would not trust the CIO to re-architect the organization."  The highlight is mine.

If you have a CIO that is both an expert in running the business and an expert in the technology, I can't agree with this comment.  But the reality is that any CIO that has this level of skill is probably already on the CEO track.  Why stay in an "IT role" when you could be running a business (especially since there's almost a stigma against CIOs being viewed as business leaders - the CIO's glass ceiling)?  So, this is a very rare breed.

Assuming you actually want your business processes automated (a problem that spans IT and business), the question for me, then, is who would you trust?

You can't trust the CIO because they are not an expert in the business - they won't understand the subtle trade-offs in the ways the business processes need to work.  You can't trust the business leader because they are not an expert in IT - they won't understand the subtle trade-offs in the way the IT applications and SOA infrastructure need to work.

So who do you trust?  You trust the person that listens instead of talks.  The person that takes input instead of dictating.  The person that recognizes they don't have all the answers, and is comfortable with that.  The person who has built a team, top to bottom, that works this way as well.

A lot of the better CIOs exhibit many of these qualities - unfortunately the one thing they almost invariably lack is these same qualities embedded, top to bottom, in the DNA of their IT organization.  Until CIOs can address this, I have to agree with the panel: you can't trust the CIO.

On the other hand, can you trust the business owner instead?

WOA is SOA - Take 2

Wow, Ron Schmelzer reacted, how should I put it, somewhat unkindly to my last post.  Yes Ron, I did read the whole article (and Nick Gall's too!)

I guess my point was probably too subtle.  I wasn't reacting to the fact (yes fact) that WOA is a "more concrete" form of SOA (see I did read your article Ron :-).  I'm in total agreement with that.  My point was, from a naming perspective, that's irrelevant.

Let me use an analogy.  Let's say we discovered intelligent carbon-based life on mars.  Would it be better to talk about it as "intelligent life" or as "a more specific type of carbon-based organic"?  Both are absolutely true, but which one matters more?  Obviously "intelligent" is the most important attribute.  The fact that it's carbon based is interesting but, in comparison, is not nearly as important (except to a few dedicated biologists who could care less about the practical consequences of it being intelligent).

For me, the same holds true for WOA.  What's the most important attribute, that it's "web-oriented" or that it's a "more concrete form of SOA"?  The most important attribute is that it's web-oriented.  That's where the power of it comes from.  The fact that it's a more concrete form of SOA is interesting, but not nearly as important.

That's why I think we should refer to it as WOA, not "web-oriented SOA."  We need to put the emPHASis on the right syllABle... Unless you'd prefer that I call you "carbon-based organic Ron" from now on. :-)

Common Data Models Being Used Today

In a previous podcast Ken Rugg, VP of Products for DataXtend & ObjectStore at Progress Software, defined what a common model is and how it improves SOA infrastructure initiatives. In this 5 minute podcast, Ken Rugg talks about what common models are being used today, how they fit in, and how Progress’ is helping you realize the value of deploying a common model within your enterprise application infrastructure. One common model being deployed today is TM Forum’s Shared Information/Data (SID) model. By using the SID model, telecommunication companies are reducing costs because they can deploy new services faster and maintain semantic consistency across different services and systems.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

If you are a telecommunications architect looking to learn more about the SID Model, download the DataXtend SID Model Browser - it's free. You will be able to use the SID Model Browser to gain an understanding of the structure and details of the SID. Starting at the highest level, you can navigate through any of the eight distinct domain areas of this common model, inspecting the hierarchy within a specific domain, and the details of the classes and attributes contained within the hierarchy.

WOA is SOA?

Ron Schmelzer of ZapThink recently wrote an article on WOA (web oriented architecture), saying that we should really think of WOA as a subset of SOA, and that maybe it should be called "Web oriented SOA".

In theory, I tend to agree with Ron.  But we all know that, in theory, there is no difference between theory and practice, but in practice they are different.

Ron is basically saying "because WOA is a specialization of SOA, it should be considered part of SOA".  That is, in theory the more general concept is more important than the specialization.

Here's my problem though: In practice, when dealing with many parties, architecture simplifications or specializations are always more powerful and useful than generalizations.

Don't believe me?  The reason this is true is the network effect. The simpler the requirements to become part of a network, the easier it is to grow the network, the more valuable the network becomes, and the more parties that want to join it.

In contrast, generalizations work against the network effect - the more variations that are allowed, the more variations will occur, the harder it becomes to get value from the network, and the more slowly an overall network will grow (if it grows at all).

The power of WOA comes directly from its web-oriented simplicity, it's minimalism - not from the fact that  it happens to follow a service oriented paradigm.  Let's put the emphasis where it belongs: practice is more important than theory if you're trying to get results.

Have You Ever Been Beat Up By A Tiny Older Woman?

I have.

And, more recently than you might think. She had experience that I didn't and she knew how to use it. I didn't stand a chance.

Some of you know that my role on the Progress Actional product line is both external and internal. I spend a good amount of time evangelizing Actional and Service Management, but also trying to understand how to leverage community technologies to make the evangelizing easier and more permanent.

I'm trying to institutionalize the tribal knowledge Actional "elders" have learned so that the whole company benefits.

I came across an interesting article, "Now Everything Is Fragmented," just the other day on this topic. It really expressed the frustration here in the Progress Tribe, and in part the "old-school" vs. "new-school" thinking on the subject. You see, everyone wants best-practices, canned RFI answers, and even a single ROI model we can use to measure how much money Actional will save our prospects.

What they ask is easy, but, in my experience, marginally useful. Though, as I thought about this article, and my problem, I realize that I could look at two different personas - one for which this information is very helpful, and one for which it is not. People with experience, who can think, need stories. They take these stories, explore new situations and find they have what they need.

SOA What? Yeah - it's that time. And, to be honest. SOA not much! I haven't written in some time, and the article above really stuck with me. I let it run through my head on last night's swim, and this is what I got. I hope you find it interesting enough not to hate me.

But, there are a couple of generally useful take-aways, that I'd like to point out:

1. Personas matter greatly, but only in the context of your goals. In my case, I listened to my users, applied my experience, and realized that two personas would greatly simplify my model. Looking at the world that way, I'm able to prioritize my objectives and address one persona or the other (or both), and be able to explain why I'm doing so. This helps me communicate throughout the organization way more effectively.
2. Communities are about conversations. Sometimes the conversation is around content - like a best practice or ROI model - but sometimes it's about the story (experience). By nature, we're story tellers, and we need a way to capture those stories institutionally and need to train (and hire) people who can use them.

And, a final piece of advice...  This tribal knowledge, this experience, needs to be kept in the company. And, it needs to be nurtured. The people with the stories, these living databases, without them, the community not only falls apart, it simply ceases to exist. Students of knowledge, which I like to think of myself as one, know the value of experience and move mountains to get close to it.

How the Wii Will Impact SOA

I am eagerly awaiting delivery of my Nintendo Wii Fit so that I can snowboard and ski in the comfort of my living room.  The Wii has changed the way that people play electronic games.  No longer do I have to contort five of my fingers in a specific manner to cut open a patient or have an 8 year old tell me how to play soccer; a game that I have played for many years.

Here is a new way for humans and computers to interact and it is available for the masses. Even my sister, a self confessed hater of anything with a keyboard and screen attached, is telling me how she has completed the latest run on the snowboard. (She is in England where for the first time in living memory the electronic toys have been released before us in the US.)

Anyway, the way that computers and humans have interacted has had a large impact on new possibilities and the increasing the demands on processing power, i.e. you can do a lot more with DOS than with punch cards, and more with RIA than DOS. But imagine what you can do when you are wearing the interface and how many more users will now want to access the system... (See how many Wiis are sold compared to its competitors.)

SOA What? You are creating and designing your SOA infrastructure with web services, portals and RIA applications in mind, but can it scale up and provide the ability to allow the masses to access your systems and provide services that we have not thought of at this time?  The vision of the future is here. Can you and your SOA adapt???

SOA Governance and Management - the Difference

Joe McKendrick's recent post comments that many analysts are now putting SOA governance and SOA management tools into a single category. He cites arguments that they are in fact very different, stating that while governance is about managing the development and the life cycle of services, management is about the technical monitoring of such. I couldn’t agree more.

Lets spell it out: in simple terms SOA governance is focused mainly on the development process, while SOA management is focused on the 'running' aspects of SOA infrastructure. Management systems must ensure that that the business services in the SOA remain reliable and live up to the expectations of the business partners, customers, suppliers, internal users and regulators.

I believe people are confused by the various contexts in which the term "SOA governance is used." In the context of a product category it is indeed confusing to lump together products with very different uses and characteristics. However, if an organisation is designing a "SOA governance strategy" then tools to aid in the development life cycle of services as well as tools to allow those services to be monitored at run-time may be required. Some organisations may describe this latter capability as "runtime governance."

Developmental governance and run-time management tools are distinct but closely related. They both aid to make SOA successful. Increasingly they work together to form a link across the entire life cycle of development and production deployment, in terms of enforcing and sharing enterprise and business policy.

So, feel free to think about the governance of your SOA in holistic, wide-ranging terms. But when it comes to thinking about which products to use, remember the distinctions. The fog of confusion will only arise if you don't.

Data Integration in SOA

As we talk to customers and prospects who are beginning to plan or enhance their SOA, we've realized that data is often overlooked in the development of a SOA infrastructure. As a matter of fact, some SOA technologists refer to it as the "day 2" problem. Why? Well, we think it might be because application and data architects may have difficulty making informed architectural decisions about it. Below is a 6 minute podcast by Ken Rugg, VP of Products for DataXtend and ObjectStore at Progress Software, that talks about the importance of data integration in SOA, why people may forget to plan for it, and some concepts related to smart data mediation.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.