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!
Subscribe to:
Posts (Atom)