The Service Oriented Enterprise (SOE) - A Preview

Most of may last couple of years have been involved in moving organizations – especially IT – to a Service-based mode of operation. So all sorts of things around SLM and making the whole Development, architecture and operations sides of IT understand the concepts of Service. I would appreciate feedback from the community on this:

Organizations are obviously cherry picking where they want to start with this type of model, but I think this gives a better picture of the end state and how you can target a specific service offering and move from the top down to develop, implement and operate the service to users. Any comments?

The big problem that we are trying to address is that we are constantly running into IT organizations that are trying to offer a service or services to a community of users (either internal or external) without any sort of service-based operation around their activities.So, we are trying to show that becoming 'service-oriented' or moving to a service-based organization pulls all of these things together to deliver and operate services effectively on an ongoing basis.

Focus on services as provision of some "real" work in the business sense is a great approach.

Thinking in terms of services is good as it focuses groups to think in terms of their value they add, the contract they have to fulfill and their role in the bigger picture.

My concern start with service oriented architecture.

If your client is well evolved and Agile where they can really reliably, and pretty accurately map their business services to software services then it may be a brilliant idea to do so. You may be the IT innovator of the year, and I am not being sarcastic about it.

IF that is not possible, if software services do not map to business services - thread lightly. You may tangle two domains to the point where one will hold another one back, and you may be known as the "chief spaghetti architect".

My advice:

Focus on "Service Oriented Enteprise" as a model for the business architecture and submit (as in submissiveness) or tie-in software services as a value add to that Service Oriented architecture only where possible, simple and truly value adding/enhancing. (e.g. installation scheduling (software) services and BPEL workflow for your Wintel (business) services).

Yes, that is somewhat how we are using it - this was really meant to be the master diagram of our methodology - so I was just looking for interpretations and understandings of what it meant as it stands on its own. Each box represents a cycle or process within the methodology that we are building out. So, this would be the destination, and how you get there is a roadmap that we develop and integrate with the adoption of the processes and artifacts that we are developing.

This is an interesting diagram. I have several similar ones. One shows the stack of software components in the SOA infrastructure and I have several around SOA governance that starts with SOA strategy all other way to SOA management. The SOA lifecycle if you will.

Looking at you process steps, design, integrate, build, service there are some steps missing such as service orchestration to optimize business processes, testing, and deploy. But it would be difficult to fit everything on one slide.

It is hard to get what you are trying to convey with the diagram though without hearing your narrative to explain it. I do a lot of presentations and much of the diagram depends on explanation. The diagrams are just tools and eye candy.

I know - there will eventually be ~5000+ pages of methodology and process behind this diagram with much of it in progress at the moment. I was really trying to get the first impressions from this master diagram from people that are in the frame of mind to see their reaction.I think that the service orchestration piece lies as part of the SLM box that goes down the side. Testing would be rolled under 'service oriented app development'. So I think that everything has a home, and it may be appropriate that the drill down of each of these boxes to the second layer will make a lot more sense.Thanks for the feedback - just wanted some first impressions on this one to see what the reactions were - back to the content!

My feedback is to try to stay away from "red". Would you consider not using a red font or red background to indicate your customer. Visually, somepeople "read" red as a negative. I always use green, blue, black, purple as first choice and then go with yellow and red to indicate "Caution area" and "problem area".

Interesting diagram. It seems to me that there are 2 somewhat different definitions of 'service' here. From a technical perspective, SOA is an an architectural style where an application can be made up of calls to a number of different services. In this case a service is just a unit of functionality - it understands certain requests, and can send back a response.

Then there is the common usage of 'service,' which is an economic concept - something that is valuable without creating a tangible product.

You talk about, "...making the whole Development, architecture and operations sides of IT understand the concepts of Service." It seems to me that IT in general understands the concept of 'service,' but they understand the technical definition - they are the ones writing the code for these services after all! This diagram takes that technical definition of service and builds an economic service around that, which to me is a bit confusing. I would try to stick with one definition of service throughout the diagram.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.