Today I've finished a 4-day course on ARIS. For those of you who don't know ARIS, it's a Business Process Modelling (BPM) tool from IDS Scheer. You might wonder why I'd follow such a course? For several reasons, really. One is that BPM is a part of my daily work. Most architectural studies I do, also address the organization and especially the processes within. Another reason is that Oracle started to work with IDS Scheer about a year ago, to create the Oracle BPA Suite (Business Process Analysis). This suite is meant to bridge the gap between designing Business Processes (BPM) and developing Executable Business Processes (BPEL).
With the BPA Suite it has become possible to automatically generate BPEL Outlines from BPM processes, modelled as EPC (Enterprise Process Chains). So finally we have integration between business design and IT implementation! The good part is, we already have customers ready to use it, so I can bring my new found expertise into play.
Thursday, 6 December 2007
Service Discovery, part 1: Bottom Up
Discovering services is one of the more challenging parts of designing an SOA. I will examine several strategies and try to assess the merits and dangers of each and every one of them.
One of the easiest (but not necessarily the best) approaches is: bottom-up. Using this approach one analyses the existing application infrastucture for all available functions that can be exposed (in any way) to the environment. For example: flat files, database procedures, external interfaces, callable forms and even database tables & views. For each function you need to determine whether or not the exposed functionality is independent of other functionality. Any dependency means that there's additional functionality needed to be able to freely expose this function.
This approach will give you a large number of available functions which you can expose as services. However, there's a catch: are these the services my business needs? The answer is: No. These are the services which can be made available from the current applications within the company. This approach will NOT tell you anything about their usability.
The good thing is: it does give you a feel for the needs of the company. These applications are not here by accident.
There's one dangerous aspect to this approach. It is a technical approach to the use and discovery of services, but it is NOT SOA! Stay tuned, I will get back to this!
One of the easiest (but not necessarily the best) approaches is: bottom-up. Using this approach one analyses the existing application infrastucture for all available functions that can be exposed (in any way) to the environment. For example: flat files, database procedures, external interfaces, callable forms and even database tables & views. For each function you need to determine whether or not the exposed functionality is independent of other functionality. Any dependency means that there's additional functionality needed to be able to freely expose this function.
This approach will give you a large number of available functions which you can expose as services. However, there's a catch: are these the services my business needs? The answer is: No. These are the services which can be made available from the current applications within the company. This approach will NOT tell you anything about their usability.
The good thing is: it does give you a feel for the needs of the company. These applications are not here by accident.
There's one dangerous aspect to this approach. It is a technical approach to the use and discovery of services, but it is NOT SOA! Stay tuned, I will get back to this!
Tuesday, 4 December 2007
Off to a New Start: Changes Ahead!
Doh, never thought it would be so hard to keep a Blog. Day to day business takes up so much time I never seem to get around to post new stuff. But, last night I gave a presentation to my co-workers about the things we're going to do around SOA, that I got triggered again to write some more.
What was it that triggered me? For that you need to understand the environment I work in. The company I work for, Inter Access, has a business unit Oracle Technology, where I am an architect. Within that business unit, we have 3 lines of business: Technology (mainly SOA projects), EBS (Oracle E-business Suite, focussing on Healthcare) and Managed Services. During my talk last night I realized that this will change in the next few years. Why? Well, I've been to Oracle's Open World in San Francisco a couple of weeks ago and I've been to several sessions about Application Integration Architecture (AIA). AIA is supposed to be 'SOA out of the Box'. It's a set of predefined business processes (industry reference models) linked with a canonical data model to integrate all the different kinds of ERP solutions that Oracle offers. I expect that we will be able to extend AIA to also include other existing applications, as well as custom made applications.
That will mean that AIA will become the heart of the solutions we are going to offer. This will effectively lead to our separate skills on Fusion Middleware and Fusion Applications will merge. Is this a good thing? In my opinion it is, as we will be able to support a larger audience. It will be a lot easier to implement an SOA when you have a lot of standard processes and default interfaces ready on the shelf.
We'll see.... it will take some time!
What was it that triggered me? For that you need to understand the environment I work in. The company I work for, Inter Access, has a business unit Oracle Technology, where I am an architect. Within that business unit, we have 3 lines of business: Technology (mainly SOA projects), EBS (Oracle E-business Suite, focussing on Healthcare) and Managed Services. During my talk last night I realized that this will change in the next few years. Why? Well, I've been to Oracle's Open World in San Francisco a couple of weeks ago and I've been to several sessions about Application Integration Architecture (AIA). AIA is supposed to be 'SOA out of the Box'. It's a set of predefined business processes (industry reference models) linked with a canonical data model to integrate all the different kinds of ERP solutions that Oracle offers. I expect that we will be able to extend AIA to also include other existing applications, as well as custom made applications.
That will mean that AIA will become the heart of the solutions we are going to offer. This will effectively lead to our separate skills on Fusion Middleware and Fusion Applications will merge. Is this a good thing? In my opinion it is, as we will be able to support a larger audience. It will be a lot easier to implement an SOA when you have a lot of standard processes and default interfaces ready on the shelf.
We'll see.... it will take some time!
Monday, 10 September 2007
Business driven?
I've been attending several seminars on SOA lately, and all presenters agree on one issue: SOA should be Business Driven. I really do agree with that, but it also made me wonder: why is it that it's mostly the IT vendors who are pushing SOA?
The principle of SOA can be stated as: separation of concerns. In my mind, that's the central theme of SOA. Separation of concern isn't anything new to IT. Ever since I started in the early 80s, we've been trying to solve problems by decomposing them into smaller pieces where each piece addresses a distinct part of the problem. Service orientation, which is the means of SOA, defines the characteristics of these pieces, like loose coupling, autonomy and statelessness. So it is no real surprise to see the IT vendors jumping to it.
But SOA is more than just the technological approach. The separation of concern can also be applied to the business. Look at Business Process Management for instance. One of the techniques that's used here is Process Analysis, which consists mostly of decomposing processes into smaller, clearly defined sub-processes.
The one thing that differs in SOA from the 'old-skool' approach of decomposition is that it also adds the concept of Orchestration. Orchestration is the means by which business functionality (whether or not automated) is structured and executed. And isn't that where the business value comes from .... ?
The principle of SOA can be stated as: separation of concerns. In my mind, that's the central theme of SOA. Separation of concern isn't anything new to IT. Ever since I started in the early 80s, we've been trying to solve problems by decomposing them into smaller pieces where each piece addresses a distinct part of the problem. Service orientation, which is the means of SOA, defines the characteristics of these pieces, like loose coupling, autonomy and statelessness. So it is no real surprise to see the IT vendors jumping to it.
But SOA is more than just the technological approach. The separation of concern can also be applied to the business. Look at Business Process Management for instance. One of the techniques that's used here is Process Analysis, which consists mostly of decomposing processes into smaller, clearly defined sub-processes.
The one thing that differs in SOA from the 'old-skool' approach of decomposition is that it also adds the concept of Orchestration. Orchestration is the means by which business functionality (whether or not automated) is structured and executed. And isn't that where the business value comes from .... ?
Saturday, 1 September 2007
Why Service Orientation ?
Service orientation is rapidly becoming mainstream. What makes it so valuable? Is it just another new hype that will blow over soon? SOA is supposed to be business driven, so how come it's being pushed so hard by IT vendors? Are there any people out there doing SOA, or is it just talk? Means using webservices you have an SOA? Where does technology comes in? What's the best technology for SOA? Is there a methodology for SOA?
I will be posting my thoughts, but more important: my experiences, upon these questions in this blog. Not that I have all the answers, though. It will be interesting to see who's got the answers, or how we go out to get them!
I will be posting my thoughts, but more important: my experiences, upon these questions in this blog. Not that I have all the answers, though. It will be interesting to see who's got the answers, or how we go out to get them!
Subscribe to:
Posts (Atom)