Page 2 of 2   « previous page

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.

Page 2 of 2   « previous page