X hits on this document





5 / 9

Five best practices for deploying a successful SOA

Proof of concept When there is no prior experience to provide tested information about making a major SOA design decision, it is beneficial to consider doing a proof of concept. You want to avoid a failed or wrong decision, which could result in penalties. Because many SOA transformation projects involve the migration of proven and time-tested systems to new technologies, products and concepts,

it is strongly recommended to use the proof-of-concept approach. Make it a best practice to start with a small, more affordable and quick test implementation to help provide the information necessary to make overarching strategic decisions. Consider developing a portion of the functionality that covers a narrow, but horizontal, end-to-end layer of your larger implementation. And, if the business process you are focused on is highly complex, consider conducting small iterations of the final implementation to help verify the applicability of the concepts as you progress.

Creating linkages from IT to your business The term SOA indicates that your goal is to implement an architecture that transitions IT into the role of a service-oriented provider for your business functions. This goal requires a purposeful effort to link IT to your business processes with a focus on future business process design—that is, you need to envision SOA solutions by examining how the business processes should run, not how they currently run.


A major challenge is that most business analysts do not have the ability to document requirements, processes and services accurately to facilitate the general alignment of business and IT. Business process modeling provides an effective method for tracing life cycles of key business entities to yield simple, flexible business process models with consistent task granularity to more easily gain consensus among different stakeholders, both at the business and IT level. However, your business process model may be error-prone, because many organizations use structured programming tools and programming constructs erroneously. If high- level business process models are erroneous, it is difficult and expensive to refine them into executable business processes. Correcting the process becomes even more expensive if the process model is later changed, with the same errors corrected multiple times when the model changes are propagated to the implementation. Model quality is critical, and any errors should be identified and eliminated from the first iteration.

Document info
Document views27
Page views27
Page last viewedWed Jan 18 06:18:20 UTC 2017