I am not, repeating not, trying to re-open the many debates on "What is SOA,". That said, the section on Vendor Lock-in, IMO, invalidates this person as an expert on the topic matter and as for the rest of the piece, there's not enough details in any one section to be of use for positive or negative review.
JP On Sat, Jan 17, 2009 at 10:39 AM, Gervas Douglas <[email protected]> wrote: > You can read the following article at: > > http://www.soainstitute.org/articles/article/article/soa-readiness-a-perspective.html > > Gervas > > <<What is SOA? > > To be ready for something you first need to understand what it is. SOA is > often defined in technical terms about the composition of services. Whist > technically correct this encourages people to become caught up in > technologies and constraints very early on. > > I prefer to think of SOA as a solution approach that helps IT solve business > problems by sharing and re-using: > > Information and data e.g. user directories > Functionality e.g. quote generation > Know how e.g. this data lives here and is looked after by X > > This is achieved by investing in sustainable system interoperability which > allows you to: > > Consolidate your maintenance costs around a smaller number of shared > services > Reuse existing services and avoiding unnecessary development > > The main benefit of this sharing and reuse is a reduction in your Total Cost > of Ownership (TCO). > > What's the problem? > > Since SOA is a form of solution it can only be effective if it solves the > problem at hand. So the second step "in being ready" is to clearly > understand the problem that you are trying to solve. > > If your problems are things like: > > We have really useful data trapped in legacy systems that we would like to > release to new user groups to increase customer satisfaction > Our admin processes are manual, inefficient and costly as we continually > re-key the same information in multiple systems > We find it really difficult to get our existing systems to communicate with > new supplier systems > Our business systems cannot scale to meet our continuously growing user > community > > Then the SOA may well be appropriate for your organization. > > If on the other hand your problems are things like: > > We need to get a Web presence ASAP to support our sales staff > We need to be able to change content on our website on a daily basis > > Then the case is less clear. The solution to these problems may work well > within an SOA context. But these requirements in themselves do not justify a > SOA approach. > > A rough rule of thumb is if your business problems are strategic rather > than tactical in nature then SOA could well play a significant role in IS > delivery. If your business problems are short-term in nature then SOA is > unlikely to represent a value for money strategy in that time span. > > How will SOA impact me? > > Most of the basic tenets of good requirements gathering, system design and > implementation are just as true for SOA as they are for OO, web or > procedural development. However, a SOA approach is unique because of its > emphasis on cross organizational sharing. Consequently, it does challenge an > organization to change how it thinks, communicates, delivers, supports and > manages. Understanding the impacts of these changes is an essential step in > being ready. > > Organizational Change > > SOA requires people to share information across the business. This requires > people to change fairly significantly in how they think and operate. People > tend to think that if they share they will: > > Gain dependencies and become less effective > Lose control > Become redundant > > Change is likely to be opposed both explicitly and covertly as people look > to protect their interests. People will only embrace this change when they > feel there is a clear benefit for them. A significant amount of education > will be required to achieve this. > > Communication Channels > > An organization will have to invest in both informal and formal > communication channels to promote information sharing. > > Governance > > SOA will initially require a Governance function as you will not achieve > business wide coordination without some degree of control. The challenge > here is the same with any management function. Keep it at the right-level > and mentor your stakeholders so they become self-governing as much as > possible. > > Budget > > Sharing information and processing across an enterprise means a single > initiative may involve multiple departments. A budgetary approach that > allocates budgets on a departmental basis may struggle to encourage the > level of collaboration necessary to deliver an optimised solution. > > Business Process Re-engineering > > SOA enables business process re-engineering. Your analysts must be skilled > in gathering business requirements so they can analyse a process and remove > redundancy. This is very different to taking a list of features and > implementing them on a SOA friendly technology stack. > > For example, a legacy process may have a sales team selling using system A > and an admin team processing using application B. The newly optimized > process may have the sales team also completing a large amount of the admin > tasks at the point of sale via a single interface so rendering application B > redundant. > > SOA and Messaging > > Messaging is at the core of SOA. It should become the new single enterprise > wide language for your systems. At a minimum this requires your team to be > proficient with: > > Messaging standards, technical and industry > Messaging patterns > Message versioning > XML and XML definition language > > It is unlikely that your team will have all these weapons in their armoury > on day one. This must be addressed through formal (e.g. training courses, > enterprise message repository) and informal (weekly meetings, best-practice > workshops) means. Otherwise, your SOA initiative will flounder as it grows. > > Building Services incurs costs > > Services offer an alternative interface to GUI applications for accessing > business functionality. Consequently, the following costs will be incurred: > > Implementing and supporting a Service Registry to publish and manage your > services > Implementing and supporting a security layer to secure access to your > services > Implementing remote invocation, error handling and transaction handling > mechanisms > Implementing message validation and translation layers at each client and > service > Providing the necessary bandwidth to minimize latency issues in accessing > your services > > Some of these are up-front costs which can be borne over the life-time of a > program. Others will occur repeatedly. The right choice of tools can help to > minimize some of these. But, implementing a function as service will always > prove more costly than implementing a function as a local library. > > Services have technical limitations > > All technologies have limitations and services are no-different. The > principal limitations of distributed services are: > > Transaction control > Exception handling > Latency > > If your designers and developers do not understand these they will end up > implementing services that do not function or 'fail' gracefully. Moreover, > given the natural latency of services and their 1distributed nature certain > exception types are more likely to occur than with homogenous tightly > coupled systems. > > XML development requires specific expertise > > XML is complex and has just as many pitfalls as any other form of > development. Many XML based applications end up being significantly > re-written because of crippling performance or quality issues. A vast array > of XML development tools exist, each suitable for a different problem. It is > essential that the development team is appropriately skilled in these > technologies. > > SOA Platforms & Tools > > SOA isn't short of feature rich platforms and tools. Typically these are > expensive and functionally rich. Unfortunately, the teams that use them are > often not adequately trained in their usage. As a result hacks are > introduced and wheels re-invented at great cost to the overall > implementation and subsequent maintenance. > > Services require testing > > Testing a programmatic or message interface is often alien to traditional QA > teams. It is unsatisfactory to rely on user-interface testing alone to > validate a service as fit for purpose. Also, services require very specific > types of concurrency and disaster recovery testing. The QA team must be > up-skilled to provide this function; otherwise system maintenance will prove > expensive. > > Client applications require repeated Testing > > If an interface affecting change is made to a service then all client > applications with a dependency on that interface must also be regression > tested. Automated testing needs to be adopted early and systematically. > Otherwise, the test effort will start to inhibit the ability of your > organization to react to change. > > SOA Deployment > > SOA encourages separation of concerns and partitioning. Consequently, you > will initially invest in more hardware and software than a traditional > architecture. The upside of this investment in computing resource is a real > ability to scale to meet increased business demands. If the 'ability to > scale and grow' is not a real requirement then this investment may not be > appropriate. > > Services need Maintenance > > New services will tend be deployed on a new technology platform. This will > require support staff to be trained in its maintenance and support. If old > systems are not-deprecated in tandem with the release of new systems the > overall TCO will increase. > > Vendor Lock-in > > SOA (and ESB's) ability to offer loose coupling between systems is often > promoted as a way to avoid vendor lock-in. In reality, the various > applications and services that comprise a SOA will still need to be > vitalized on a regular basis. Also, every ESB on the market today has a > finite support life time so they in themselves just provide another lock in > point. > > Vendor lock-in is unavoidable in any enterprise IS. The best strategy is to > pick the vendor that best suits your profile, adopt popular industry > standards where possible and try to be smart about how and when you > upgrade. > > So are you ready for SOA? > > Being ready for SOA means you have defined your problem and understand the > costs, benefits and limitations of this approach. > > SOA does have upfront costs and does encourage an 'economies of scale' > mindset. But the good news is that you can and should embrace SOA > incrementally. > > In all likelihood you will have already delivered some services in your > business and can probably look at re-using these more. If not, integrating > with a specialist service provider is a reasonably low-risk way of > introducing services into your enterprise. > > > 1 Often a service may be provided by an external supplier or different > department to the client application. As a result they will have different > support windows and/or may not be as reactive as desired in the event of a > system malfunction.>> > >
