State of Play in SOA
AMR has published a research report on Service Oriented Architecture (SOA). They share the findings from a survey of 134 companies on their understanding of SOA, current deployment status, and future plans.
If you're not an AMR subscriber, Line56.com has a quick overview. Part II was published today.
The results of the survey synchronized very closely with the Accenture/SAP study noted below in terms of the reasons why companies were implementing SOA. There are a wide variety of equally valid reasons for pursuing architectural modernization, but flexibility appears to top the list.
Food for thought coming out of the AMR study:
One of the main questions in designing SOA is where do you draw the line. At what level do you componentize your infrastructure? This is a critical decision, since if the lines are drawn too narrowly, your IT staff will be overloaded with work trying to assemble meaningful application functionality out of very granular components. For example, think of isolating and componentizing a function like bold text so that it could be called as a service from every application. Conceptually it's interesting, but practically it's nonsensical. This is app-level functionality, and you probably already have it everywhere you need it.
On the other hand, if the lines are drawn too broadly, you begin to lose some of the advantages of SOA. If transactions or records or processes are lumpy and you cannot introspect them, then you cannot impose rules which will intercept, flag, alert or reroute. To make matters more complex, this question of where to draw the lines has to be decided at the level of Web services, portal, application servers, integration framework, security framework, analytics framework, enterprise service bus, and BPM framework. And it has to be decided at the CDI level as well.
One of the primary advantages of buying CDI solutions instead of building them is that the responsibility for upgrading the application over time rests with a vendor instead of in-house staff. Of course, if upgrades are significant then the in-house software upgrade effort may be correspondingly large, but at least you do not also have the development effort. Companies considering CDI solutions need to look carefully at the levels at which various software packages expose services for external consumption, and examine the fit with current SOA plans. This consciousness needs to extend into the CDI implementation plan as well, as companies need to think about how BPM processes will be maintained and migrated in a software upgrade. (At a minimum, they need to stored out of line with the primary package installation, so they do not get overwritten in an upgrade!)
If you're not an AMR subscriber, Line56.com has a quick overview. Part II was published today.
The results of the survey synchronized very closely with the Accenture/SAP study noted below in terms of the reasons why companies were implementing SOA. There are a wide variety of equally valid reasons for pursuing architectural modernization, but flexibility appears to top the list.
Food for thought coming out of the AMR study:
Among companies that are already using SOA, 36 percent find themselves unable to reconfigure business processes as needed. This is only a problem for 13 percent of those companies that have not yet adopted SOA.Given that enabling enterprise-level business processes is one of the principal goals of CDI, this has ramifications for your CDI strategy, specifically on the issue of build vs. buy.
AMR posits two reasons for this development: a limited deployment of business process management (BPM), "the orchestration layer used to reconfigure business processes... even among those who have deployed SOA, only 14% have deployed BPM," and the size, number and complexity of legacy systems, which make business processes "immensely difficult to service-enable."
One of the main questions in designing SOA is where do you draw the line. At what level do you componentize your infrastructure? This is a critical decision, since if the lines are drawn too narrowly, your IT staff will be overloaded with work trying to assemble meaningful application functionality out of very granular components. For example, think of isolating and componentizing a function like bold text so that it could be called as a service from every application. Conceptually it's interesting, but practically it's nonsensical. This is app-level functionality, and you probably already have it everywhere you need it.
On the other hand, if the lines are drawn too broadly, you begin to lose some of the advantages of SOA. If transactions or records or processes are lumpy and you cannot introspect them, then you cannot impose rules which will intercept, flag, alert or reroute. To make matters more complex, this question of where to draw the lines has to be decided at the level of Web services, portal, application servers, integration framework, security framework, analytics framework, enterprise service bus, and BPM framework. And it has to be decided at the CDI level as well.
One of the primary advantages of buying CDI solutions instead of building them is that the responsibility for upgrading the application over time rests with a vendor instead of in-house staff. Of course, if upgrades are significant then the in-house software upgrade effort may be correspondingly large, but at least you do not also have the development effort. Companies considering CDI solutions need to look carefully at the levels at which various software packages expose services for external consumption, and examine the fit with current SOA plans. This consciousness needs to extend into the CDI implementation plan as well, as companies need to think about how BPM processes will be maintained and migrated in a software upgrade. (At a minimum, they need to stored out of line with the primary package installation, so they do not get overwritten in an upgrade!)
0 Comments:
Post a Comment
<< Home