Good Webinar on SAP Netweaver
Check out this webinar on SAP Netweaver and listen to Amberpoint about their service management tools.
Microsoft readings in SOA/BPM space
Here is a number of papers from Microsoft, relating to service-orientation.
BPEL & Humans
BPEL is said to be designed for orchestration of web services. Some say BPEL is competent and suitable for business process implementations, but not for human workflows. I've also read that BPEL lacks in the way it orchestrates human interaction with business processes. I think one should separate those two scenarios from each other since they will have different impact on the critisism.
First, BPEL cannot describe a human workflow and I don't agree. A business process contains a flow with several descions on the way forward. A human workflow is the same where the flow is central, except that humans makes the descisions them self (in their head based on facts in that very moment). A business process will make a descision based on predefined rules. Where a BPEL process goes to a Rules Engine to make descision for a business process, a human workflow asks a human. The human is responding through web services.
Secondly, BPEL cannot communicate with humans. BPEL use partner links for inter communication, where a partner link is pointing out a web service endpoint. Yes, it's an endpoint and not a human, but behind the endpoint there can be a human. Some say humans are resource when someone asks for a role. The same thing can be said about web services. A web service interface is a role, where the running instance is the resource. Allocation of resources is handled by resource management tools in the same way as SOA tools handles service management.
I'm sorry, I can't see why humans are different when it comes to processes and services.
Meta-applications
A classic application is like a black box of functionality which can be accessed and used by opaque interfaces. What's happening inside the application is not your business, but it guarantees the job will be done. A classic application is building trust by taking care of your data as long as you don't mess with how it's getting done.
In a service oriented world where services are used and reused as building blocks, the black box is gone. A SOA is transparent and built up of composite services. A SOA consists of meta-applications which consists of services. A meta-application is a set of services using the same policies as a trust boundary. With service governance the trust of meta-applications will be as high as for classic applications, or will it not?
Programmer, take control over your process!
Think about the code you are writing for a second. Where do you implement the business process? First of all, let's define a business process.
Figure 1: Process flow is like a pipeline controlling access to the business objects over time.
A business process controls the state of a business object over time. Think of a process as a pipeline controlling incoming and outgoing messages, from and to the process flow. Only predetermined access is allowed to change the state of the business objects. This is just like normal code execution. No one except the programmer can control the flow of the execution for a specific program.
puts("Enter your age:");
gets(age);
if (age>30)
printf("Welcome! Enter your name please:");
else
printf("Yo! What's your name?:");
gets(name);
printf("Hello, %s", name);
In the code above the flow defines how we are handle the dialog with the outside world in C, just like a pipeline. No one can change this flow after it's deployed. This code is totally in control over the state change of the dialog. Eventhough a modern programmer writes code in this way, the general business application never controls the business objects. Why is that?
System design as it is practiced today, business processes are everywhere and anywhere. They are implemented in the database as triggers/SPs, in windows services, in web applications, in desktop apps and in middleware. The processes is not centric (like the C code) and cannot be controlled and managed in a centralized manner.
The reason for scattered process definitions or no process definition at all is deeply rooted in the programmers mind. He takes control over his execution flow, but doesn't take control and responsibility for the business flow. Instead of taking control over the business flow, the business objects are open for arbitrary access and state modification over time. A programmer's way of thinking is related to not understanding the business' needs, but also in the lack of tools and languages for writing process-centric applications.
Controlling the business process will result in a new way of designing applications. Start now, take control over your processes!
Policy-driven Management
Looking back in the history of IT, technologies have come an gone like mayflies. Some have stayed longer and some are like cockroaches which we can't get rid off.
The goal for IT remains the same though while the roadmap seems to be rewritten for all new technologies entering the market. Indiviual vendors doesn't have the patiance to be lasting and durable in the market and therefore tries to find the short answer to the roadmap.
With a couple of years behind us, following the adoption of XML, we are now seeing a pattern where standardized technologies enabling each other. Web Service couldn't be realized without XML eventhough Services were a well known term in IT. Same goes for SOA, an architecture for making services managable, reachable and reusable.
BPM (Business Process Managment) might be a successfull design, but based on SOA it will reach new hights and dictate the new way for building software. BSM (Business Service Managment) will leverage on BPM and be the last enabler for the main goal for IT.
The goal for IT will be to fully manage IT with a policy-driven management approach. A situation where the business policies dictate what service will be used for different processes.
It's about People, Business and Software
Office 2007 and Vista are on the horizon and MS is starting to polish on the vision for the products. With People-Ready Business the new products will get packaged and deployed to the market, but what is the meaning of the announcement?
People is an important pillar in an enterprise where (let's say) Business and Software are the other two. Combining the three pillars with readiness (as the measurement for how they are related to the vision) will create 6 different messages. Below are the permutations of People, Business and Software in terms of readiness:
- People Ready Business
- Business Ready People
- Software Ready People
- People Ready Software
- Software Ready Business
- Business Ready Software
It's a long shot, but isn't that the SOA marketing message we are talking about here?
The first step towards SOA
Some leading SOA guidelines talks about understanding your business, processes and domains in advance of implementing any supporting tools. Understanding one's business is good but a SOA project probably have no use of that information initially. Starting with the big scope is often why those projects never see the day lights.
SOA implementations does not need to know about implementation details, such of business processes, data services, etc. This type of information is related to projects (such as BPM implementations) enabled by a SOA. The first step would instead be to build the foundation for your SOA (i.e. service governance tools). While many analysts and consultants recommend their clients not to go with a product-first-approach, that is definitely my number one recommendation.
The next step would be to make use of the SOA. The first project would preferably be one that leverage on all good things with SOA, but doesn't interfere with the day-to-day operational work. BPM implementations are the most obvious one in terms of making use of service governance. BPM is a top-down approach that will give you the services needed from a business process perspective. When you have defined your processes, a couple of service will be implemented as a result.
The third step would be to roll out a large scale BPM project and make your applications SOA-ready.
SOA-ready vs. Full-SOA applications
Applications can be more or less ready for a SOA. A non-SOA application is one without any service endpoint, which almost never exists. Each application would have some form of interface, whether it's a GUI or an API. If you got a no-empty interface, you got services!
Functions can be exposed using a service facade accessable from other applications. An application where you have created web service endpoints on top of the APIs is a SOA-ready application. A SOA-ready app is characterized as a black-box, built for a specific function but extended to support cross-functional services. They got immutable boundaries framing the application functionality, accessing internal datasource and internal transaction scope only. Applications as we know them today are SOA-ready whenever they are extended with a service layer.
The next generation of applications are Full SOA enabled. The functional black-box is gone and replaced with an extensible boundary based on access policies. A Full SOA app can rely on external datasources and transaction scopes, which will make it possible to route data access to an external source. They are orchestrated in terms of how they use other services, which will give the benefits of BPM. A Full SOA app is not an executable, it's a configuration of how services interact with each other.
Is SOA about reusability or agility?
David Chappell talks about SOA and reusability as if they relate to each other. I can somewhat agree , but from my point of view reuse isn't the main benefit of SOA. I would say agility is the main benefit and the foremost design goal for SOA.
Comparing reusability and agility in terms of which one is the easiest to achive, reusability is by far the harder challenge. Impediments to effective reuse are deeply rooted in human nature. Agility on the other hand is not.
While reusability belongs to object orientation, agility is the goal with service orientation and achieved with loose coupling between services in a SOA. David is mentioning service orchestration as the way of reaching loose coupling, but doesn't that relate to process management? I recently posted a few rows about the aspects of loosely coupling when it comes to service management and process management. I would say that agility can come from either, but a distinction between SOA and BPM need to be discussed.
Design approach
Some claims that Service Orientation is bottom-up and Process Orientation is top-down. Since a process is encapsulated by a service, this service is higher up in the design then the encapsulated process. But, this service is on the other hand used by another process which puts that process up higher in the hierarchy. But who knows, there might be a service on top of this process as well. So, with mathematical induction one can prove that none is more top-down than the other.
SOA vs BPM
Are SOA and BPM competing with each other, in aspect of making apps more loosely coupled?
The main idea with SOA is to be in control over the endpoints and the traffic between them, right? Service Management let you reroute the traffic between endpoints depending on content, header, etc. All this Service Management stuff make the parts of a system more loosely coupled to each other and easier to reconstruct on the fly.
BPM has a similar goal of making things more loosely coupled. But the way Process Management handles loose coupling is by making the execution path more managable. In the same way Service Management can modify the traffic flow on the fly, Process Management can modify the flow of messages between subprocesses or other services. That type of managability is related to the flexibility in the implementation of the service, rather than the coupling between them.
Subscribe to:
Posts (Atom)
