Jack van Hoof contacted me about his IT Services Stack collaboration experiment.  Jack, as many know, is an enterprise integration architect and author of the popular eda-soa blog.  In his email, Jack asked if I would let my readers know of his experiment and offer my feedback.  Since the work will remain in the public domain, I'm happy to do both.

The Initiative

The best way to describe the work, is to excerpt from Jack's post and show his picture in progress.

"It is not always easy for an enterprise IT architect to keep scope and hold the complete picture. As we have several architects with different competences I felt the urge to develop an IT Services Stack. The IT Services Stack is a picture of a layered view on all aspects of IT from a component perspective."

"I would like to make this premature IT Services Stack more consistent and supply an extended view on every component mentioned in the picture. The model should be defined one level deeper, with the following attributes:

• Function of the component
• Relationship with other components
• Sub-level components and models
• Related open standards
• Innovative products in the market"

Jack then asks for community help, that's us.  So, if you are inclined, jump over to Jack's blog and offer your comments.  Or, as I'm about to do, post your comments and link to Jack.

My Three Cents

I suggest the addition of a new (leftmost) column, IT Business Management.  This column would contain components related to the 'business of IT'.  Top of mind components are:

• Business & IT Collaboration: Strategy, Architecture, Planning
• IT Offerings - the products and services IT provides to the business.  The supplier might be a third party.
• Demand and Supply Management
• Portfolio Management - Budget, Project and Asset
• Talent Development

The Hardware section caught my eye, only because I wonder how much hardware will continue to be under direct management of IT.  Beyond interaction devices (laptops, keyboards, mice, pdas) and networking equipment, does hardware ownership and management by IT organizations become obsolete?  Do we care about the hardware?  Or, just the technical infrastructure services at the next layer up?

In respect to the SOA box, the SOA Consortium's community of practice is working on a planning framework.  I sense some sharing in our future.

[Disclosure: The SOA Consortium is a client of my company, Elemental Links]

Posted by brendamichelson in bda community projects • enterprise architecture • general IT | Permalink | Comments (1) | TrackBacks (0)

Last Friday, I asked if readers were interested in collaborating on questions related to business-driven architecture. This was inspired by a comment from James. Continuing the community-driven theme, I shared a suggested starter question from Mark G.

So one question I would love to hear discussion on is how to prepare your IT organization for Service Orientation. I am curious to see how others are approaching this or not approaching it. I do see it as a challenge for your typical corporate IT shops as oppose to software vendors. What do you think? Is this a big issue for your shops? My gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA. Is this something worth discussing/addressing? Is everyone even looking at SOA now that the hype is at fever pitch?

Some readers sent emails indicating their interest, while others jumped right in. In this post, I'm wearing my host/facilitator hat. I intend to highlight some of the conversation points, provide a chronological tracking of the conversation across the participating blogs (posts, comments and trackbacks) to ease new participant entry, and ask some questions to keep things going. In the spirit of keeping the conversation connection, I'll throw trackbacks from this post. I invite all practitioner readers to participate in this conversation. Here at BDA, on your own blog (please throw me a trackback), and via comments on the community member blogs.

But first, a little housekeeping. Elizabeth Book, ebizQ's editor-in-chief, responded "Absolutely" re: publishing any BDA community generated content. As well, to ease our interaction, the ebizQ technical team added permalinks for individual comments, and you can now subscribe to a comment/trackback feed. [Also available in the Subscribe section of my right sidebar.]

The Conversation: How to Prepare Your IT Organization for Service-Orientation?

[Please note the emphasis below was added by your facilitator]

Todd started the conversation on Tuesday. He disagreed with Mark's "gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA."

Todd stated:

"I think a strong background in these technologies will assist in building service-oriented applications, but I don’t think it will go very far in yielding service-oriented architecture. The reason for this is that as long as all of the IT effort remains within the constraints of a single project, the organization will never understand it means to be a service provider...

...To me, the ability for an organization to succeed is going to be highly dependent on their ability to communicate, collaborate, and manage the service lifecycle, independent of whatever technologies are involved. I had the opportunity to comment about this in the a recent ZapThink podcast."

Mark replied:

It makes me think that when addressing SOA conversations, it’s important to distinguish between the technical aspect and the business aspect.

One thing an EAI competency center helps with is a larger view of the business as well as the various projects within an IT organization. These centers often have a much better view of the world than individual development groups within an IT organization...This one group however cannot transform the entire IT organization however, which is the thought behind my original post. How do you get your IT organization to that state which you are describing?

Anil John joins next, adding important points on SOA being about the business, and the tie between SOA governance and enterprise architecture:

As a technologist it pains me to admit this, but SOA is NOT about technology. It is among other things, identifying the capabilities that are offered by the business unit, having a clear understanding of the processes that make up those capabilities, and making those processes available for reuse via standardized interfaces to the enterprise at large.

...if the culture already has a good governance process in place as part of its Enterprise Architecture, adding the bits that enable governance for SOA is an incremental addition and not a big culture shift. And this addition very much improves the chances of success of the SOA implementation, given that lack of governance has been cited as one of the prime reasons for the failure of SOA implementations.

Todd and Anil are in agreement on a business-first approach. Todd then shares some (good) business process analysis questions to jump start developer's thinking:

1) What services does your solution use / expose?
2) What events does your solution consume / publish?
3) What business process(es) does your solution support?

Knowing Todd, I'm pretty certain "services" in question #1 refers to abstract business services, rather than technical implementations.

At this point, Mark returns here, agreeing with Todd and Anil that a critical step in preparing an organization for SOA is understanding and focusing on the business. However, he brings up a good point, that IT still needs to deliver:

Is it possible to focus on the business but forget that at the end of the day you still have to deliver what you promised? This would be the loosely coupled, reusable and agile services that make up that business process.

The reason I asked is that I have seen many EAI and EDA architectures fail because either the industry/vendors or the IT shop trivialized the technology piece. It's one of those if it were easy then everyone would be doing it. I can tell you that loosely coupled, reusable, agile services are not trivial to most corporate IT shops.

Mark then suggests a natural fork for the conversation:

So maybe the conversation should fork into how do I get my IT organization more involved with the business to really understand it? And how do I make sure that my IT organization can deliver the services that will enable that understanding? What do you think?

Anil and Todd both chime in on steering clear of business process paralysis. Anil offers a mixed top-down bottom-up approach:

Approaching SOA from both the Top-Down/Business Process perspective as well as the Bottom-Up/Service Factoring perspective allows for the identification of the re-usable aspects in a business process and to realize that re-usability using the service implementation technology of your choice. In short, this helps you build the right type of services that are reusable across the Enterprise.

Todd comments on finding the right scope:

Bottom-up efforts are more easily embraced because the starting point is well defined. Top-down efforts, are not so easily embraced. How high up do you go? I think this depends on your resources and the ability of those with business knowledge to contribute. You need to look broader than the bottom-up project at hand, but beginning at enterprise may be too far away to be practical. If the answer was easy, we’d all have done it by now.

Potential Questions to Continue the Conversation:

1. Yes, understanding the business is critical in preparing an organization for SOA. But what else? As Mark asks, how can he ensure his organization is ready to deliver?

2. And the other fork from Mark: "How do I get my IT organization more involved with the business to really understand it?"

3. What tools and/or methods are effective for top-down, bottom-up business and service modeling?

4. How about that "elusive" governance? How do you sell Governance to IT and Business Leadership? Where do you get the money for people, process and tools? How do you convince people "Governance is good for you" rather than "Governance is a roadblock"?

I'd be remiss if I didn't thank our contributors to date. Great thinking. Also, I want to emphasize this is open participation, the more brain power the better!

Posted by brendamichelson in SOA • bda community projects • business driven architecture | Permalink | Comments (4) | TrackBacks (2)