Optimising SOA: resolving disconnects
November 23, 2008
SOA has matured to well beyond start-of-the-century vendor speak. Now, with Frank Kenney's blog fresh in my mind, I want to focus on achieving optimal SOA.
As with most best practices, achieving optimal SOA is actually easier said than done. This is because a SOA architecture is typically driven by an ad-hoc case to meet a technical need and not a business need. Currently there is plenty of anecdotal evidence to support this.
Naturally the case for optimising SOA does assume that a mature SOA strategy is already in place. Otherwise, you will need to complete that pre-requisite step of properly architecting your SOA strategy. Firstly look at the broad principles: start with governance including ownership and deployment policies. Then look at overarching approaches to security, performance, business scope and interoperability. This will help define the requirements for an ESB (Enterprise Service Bus). If you have an existing service repository then you will want to look at whether there is a case to create a second repository, or to continue using the original repository, or to migrate to a different (perhaps less proprietary) repository such asIona (sorry, broken link as at September 2019!) or Open ESB.
And that is where the first disconnect occurs: business and technology.
The first need here is to look at what the business is requiring. Don't just look at functionality. Be tenacious and look closely so you can define areas such as:
• performance
• security
• scalability
• interoperability
• reusability
I'll cover a couple more disconnects next time.
SOA has matured to well beyond start-of-the-century vendor speak. Now, with Frank Kenney's blog fresh in my mind, I want to focus on achieving optimal SOA.
As with most best practices, achieving optimal SOA is actually easier said than done. This is because a SOA architecture is typically driven by an ad-hoc case to meet a technical need and not a business need. Currently there is plenty of anecdotal evidence to support this.
Naturally the case for optimising SOA does assume that a mature SOA strategy is already in place. Otherwise, you will need to complete that pre-requisite step of properly architecting your SOA strategy. Firstly look at the broad principles: start with governance including ownership and deployment policies. Then look at overarching approaches to security, performance, business scope and interoperability. This will help define the requirements for an ESB (Enterprise Service Bus). If you have an existing service repository then you will want to look at whether there is a case to create a second repository, or to continue using the original repository, or to migrate to a different (perhaps less proprietary) repository such as
And that is where the first disconnect occurs: business and technology.
The first need here is to look at what the business is requiring. Don't just look at functionality. Be tenacious and look closely so you can define areas such as:
• performance
• security
• scalability
• interoperability
• reusability
I'll cover a couple more disconnects next time.
Comments
Post a Comment