SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine, Wine Blog on Ulitzer, VITO Report

Article

SOA World Cover Story — Are You Being Served?

Customer-Centric SOA Management

All of the different types of technical stakeholders involved need a common and consistent source of information about the many components that constitute the overall application so they can effectively work together, but each stakeholder also needs to consider that application and its transactions from his own unique perspective and technical requirements. It's also often necessary to examine the problematic transaction from the standpoint of both real-time operations and historical data. A historical view is particularly important when responding to customer experience problems after the fact or to determine patterns when problems appear intermittently.

You can get a feeling for how this works by considering Wily Technologies' Customer Experience Manager (CEM) and Introscope customer-centric enterprise solutions. These solutions help IT stakeholders identify and fix components that are affecting business transactions in both Web applications and SOAs. They eliminate the usual finger pointing between the different technical stakeholders by providing a common and consistent source of historical and real-time information about the components and the transactions that flow through them. At the same time, they enable each stakeholder at every level to see the information that makes sense for his role. For example, an operations person might simply see a traffic light icon indicating a red alert when a particular customer business service starts to behave erratically before the customers notice the problem. At the same time, an application support person would see that the problem occurs in a specific Java component such as an EJB and only in certain types of transactions or perhaps only transactions from a particular customer. Application support could then notify the programmer responsible for that component who would get the critical information at the individual object method level. Similarly, if the problem was database-related, another domain expert such as a DBA could get the specific SQL statement that caused the problem in that transaction from the same set of tools, and so on.

Notice that this customer-centric enterprise approach to application and SOA management draws no particular distinction between the components that we call services and the ones we call objects or back-end systems. The perspective is always customer- and transaction-centric as it should be. In fact, since the customer is the focus of this approach, it's quite easy for IT to measure and assign dollar values to every type of transaction to demonstrate and measure the value that IT provides by supporting that transaction along with tracing the path of the transaction through all the supporting systems. This kind of comprehensive measurement and understanding can only be achieved by monitoring business transactions from the customer through the middleware hosting the business logic to the back-end systems and then back to the customer.

Conclusion
Understanding business service roles and applying an architectural view of SOA focused on the customer rather than the IT organization is an effective aid in creating an appropriately customer-focused SOA. Such a focus on the customer demands an equal focus on SLAs as an essential consideration for SOA. Enterprise systems management, SOA services management, customer-centric enterprise application management, and customer-centric enterprise SOA management are all required and must work together for you to meet customer expectations and remediate problems proactively.

Without a consistent and unified view of real-world business transactions as they travel through the entirety of your SOA including various back-end systems, object-oriented business logic, business services, their supporting .NET and Java-centric middleware, as well as other components such as messaging middleware and databases, it's not possible to understand and remediate problems that inevitably occur in any complex distributed system - SOA being no exception. By taking the correct customer-centric approach to management, you may be able to avoid Groucho Marx's dilemma. Your SOA may not seem overwhelmingly complicated anymore. In fact, it may be possible to avoid asking a five-year-old for assistance.

More Stories By Paul Lipton

Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.