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!

WS-BPEL 2.0 Public Draft

Check out the new specs for WS-BPEL 2.0.

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:

  1. People Ready Business
  2. Business Ready People
  3. Software Ready People
  4. People Ready Software
  5. Software Ready Business
  6. Business Ready Software
After a couple of minutes thinking about them, one thing pops up in my head. What if we got an enterprise with people who are ready for the business. People that are competent to use the software that is created for supporting the business. Software easy to use by the people. A business that can be improved with the right software in use and effectively runned by the right people.

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.