Tuesday, February 27, 2007
How to make your enterprise a service oriented enterprise?
I was pointed at the contribution of Niels Klinkenberg to LAC 2005 with respect to SOE (Service Oriented Enterprise). The relation is made between service orientation to a network of organizaties, aimed at optimal flow. It states the conditions of success to install a SOE and make it work.
Monday, February 26, 2007
SOA in relation to Enterprise Architecture
Today I was busy with service orientation. The acronyms flew round my head. In the past I have tried to place those acronyms in the typical layers of enterprise architecture. I go back to the basics of the most elementary definition of service orientation to be able to do that.
I view service orientation as a way to view the world. With it, you devide the world into service providers and service requestors. A beautiful way to arrange the world (or enterprise or application landscape) in parts. A very old model as well, as it is the simple model of supply and demand from the economy. In short, I see service orientation as a decomposition paradigm, a classification style. Of course that is extended with ways to find what services to choose and to (re)combine services to larger wholes.
If you look at this way to the usual SOA stories, you recognize that talk about things like
webservices, enterprise service bus, certain standards (SOAP, XML, etc.). In short, technical architecture and especially the area of suppliers. This is what most books are talking about and most marketing talk. From this we recognize supporting services, like security services or transformation services or technical data services. Advantages you can get from doing SOA at this level is easy integration and better maintainability.
One level up in the enterprise architeccture, you find the information architecture. At this level service orientation is, as I understand it, about finding the correct decomposition of information area's, components or 'logical information systems'. By applying the service orientation criterium you might get a new module classification of application. I am only starting to understand the criteria to use to find those services or service units. I find the services found even less important that the service units found (you might therefor name service units to services). Internal and external application services are interesting on this level. Also, the service catalogue of COTS applications have their place here. You can compose services from here, via BPM or Mashup. I am wandering which advantages this view will have in practice.
I will go into this later.
The next level is the business architecture. The basic definition of service orientation is applicable at this level aswell. You could organise an organization as a network of service providers and requestors. In practice that is the trend in organizations. Due to outsourcing. But also within units, teams, who get the responsibility to deliver services to others. The hierarchical organization and direct supervision of HOW the work is done is disappearing somewhat. Tasks and services appear that must be performed according to specific criteria. This level I call service oriented enterprise (SOE).
At the highest level of enterprise architecture we find business context and scope. Here service orientation is the normal (economic) model. Deliver to customers as they ask.
In my current knowledge, organizations acquire the most advantages from service orientation, when operating from business context or business architecture level down. It seems that organizing your enterprise this way also helps to align business context, business, information and technology to be able to work in the same dynamics.
I view service orientation as a way to view the world. With it, you devide the world into service providers and service requestors. A beautiful way to arrange the world (or enterprise or application landscape) in parts. A very old model as well, as it is the simple model of supply and demand from the economy. In short, I see service orientation as a decomposition paradigm, a classification style. Of course that is extended with ways to find what services to choose and to (re)combine services to larger wholes.
If you look at this way to the usual SOA stories, you recognize that talk about things like
webservices, enterprise service bus, certain standards (SOAP, XML, etc.). In short, technical architecture and especially the area of suppliers. This is what most books are talking about and most marketing talk. From this we recognize supporting services, like security services or transformation services or technical data services. Advantages you can get from doing SOA at this level is easy integration and better maintainability.
One level up in the enterprise architeccture, you find the information architecture. At this level service orientation is, as I understand it, about finding the correct decomposition of information area's, components or 'logical information systems'. By applying the service orientation criterium you might get a new module classification of application. I am only starting to understand the criteria to use to find those services or service units. I find the services found even less important that the service units found (you might therefor name service units to services). Internal and external application services are interesting on this level. Also, the service catalogue of COTS applications have their place here. You can compose services from here, via BPM or Mashup. I am wandering which advantages this view will have in practice.
I will go into this later.
The next level is the business architecture. The basic definition of service orientation is applicable at this level aswell. You could organise an organization as a network of service providers and requestors. In practice that is the trend in organizations. Due to outsourcing. But also within units, teams, who get the responsibility to deliver services to others. The hierarchical organization and direct supervision of HOW the work is done is disappearing somewhat. Tasks and services appear that must be performed according to specific criteria. This level I call service oriented enterprise (SOE).
At the highest level of enterprise architecture we find business context and scope. Here service orientation is the normal (economic) model. Deliver to customers as they ask.
In my current knowledge, organizations acquire the most advantages from service orientation, when operating from business context or business architecture level down. It seems that organizing your enterprise this way also helps to align business context, business, information and technology to be able to work in the same dynamics.
Friday, February 23, 2007
Information architecture
How come that information isn't used in organizations more innovative, more consistent and more effective?
That is a question which intrigues me for years now. I search for the answers in disciplines like enterprise architecture and information architecture. Although I started searching in structure sciences, I have broadened my view to the art and science of designing complex organizations and information structures. I will explore in this blog how it can be done differently. Different from other perspectives, through serving the informationworker.
That is a question which intrigues me for years now. I search for the answers in disciplines like enterprise architecture and information architecture. Although I started searching in structure sciences, I have broadened my view to the art and science of designing complex organizations and information structures. I will explore in this blog how it can be done differently. Different from other perspectives, through serving the informationworker.
Subscribe to:
Posts (Atom)
