ServiceTechMag.com > Archive > Issue XLVII: February 2011 > Service Portfolio Management - Part II
Toufic Boubez

Toufic Boubez

Biography

Dr. Toufic Boubez is a well-respected SOA and Web services pioneer and co-author of the SOA Manifesto. He is a Certified SOA Architect and Security Specialist, as well as a consultant and Certified SOA Trainer for SOA Systems Inc. He is the founder of SOA Craftworks and the founder and CTO of Layer 7 Technologies, one of the most successful vendors in SOA Governance and Security. Prior to Layer 7, he was the Chief Architect for Web Services at IBM's Software Group, and the Chief Architect for the IBM Web Services tools. At IBM, he founded the first SOA team and drove IBM's early XML and Web Services strategies. As part of his early SOA activities, he co-authored the original UDDI specification, and co-authored a service description language that was a precursor to WSDL. His current activities span SOA Security, SOA Governance and the impact of Cloud Computing.

Toufic is a sought-after presenter and has chaired many XML and Web services conferences, including XML-One and WebServices-One. He has also been actively involved with various standards organizations such as OASIS, W3C and WS-I. He was the co-editor of the W3C WS-Policy specification, and the co-author of the OASIS WS-Trust, WS-SecureConversation, and WS-Federation specifications. He has also participated on the OASIS WS-Security, SAML and UDDI Technical Committees. He is the author of many publications and several books, including "Building Web Services with Java" and the upcoming titles "SOA Governance" and "SOA Security: Practices, Patterns, and Technologies for Securing Services". InfoWorld named him to its "Ones to Watch" list in 2002, and CRN named him a Technology Innovator for 2004. Dr. Boubez holds a Master of Electrical Engineering degree from McGill University and a Ph.D. in Biomedical Engineering from Rutgers University.

Contributions

rss  subscribe to this author

Bookmarks



Service Portfolio Management — Part II

Published: February 15, 2011 • SOA Magazine Issue XLVII PDF
 

This is second part of a three–part article series. The first part is published at Service Portfolio Management - Part I.


Gathering the Business Requirements

At this stage, the conceptual services identified are at a very high level, containing little or no details of the underlying business functional requirements. SOA governance must see to it that much more analysis is performed before we can create a service model that would be of any practical benefit to the organization.

Both dynamic models and static models of how the organization currently performs its 'hot' business processes are needed to define a realistic service model. Dynamic models describe business processes, activities and tasks, while static models describe the entities (collections of data) that the organization needs to record and manage. These entities are used as inputs and outputs for the tasks and processes contained in the dynamic business model.


Top–Down Business Process Modeling

Business processes, sub–processes, activities etc. form a natural hierarchy. If you start from a specific business process and then analyze its internals, you generally uncover a set of simpler sub–processes together with some alternate branches or decision points. These sub–processes may in turn contain internal logic that invokes sub–sub processes and so on.

The level of nesting of processes and sub–processes is arbitrary but is rarely as large as 10 in any practical example. As we progress through processes and sub–processes we rapidly arrive at individual business tasks and finally business actions or events that are performed by a single individual in a single working session. This is shown in Figure 1, which is a simplified hierarchy consisting of only 4 layers.



Figure 1 – A simple business process hierarchy

As a concrete example, consider a simple Web retail application. At the highest level is the process that manages a Web session. This coordinates:

  • a catalog search sub–process
  • a shopping cart management sub–process
  • a customer profile management sub–process
  • an order pricing sub–process
  • a payments sub–process
  • an order fulfillment sub–process (i.e. assembling and shipping an order)

Each of these sub-processes may in turn invoke sub-sub-processes or tasks. For example, the pricing sub-process will have to handle tasks such as calculating:

  • the price of each item
  • total order price, applying any quantity discounts and taxes
  • total order shipping weight
  • shipping cost
  • customer discounts
  • total cost

As we progress down such a hierarchy, we see that some of the processes, activities and tasks are common to multiple processes and sub-processes. For example, the catalog search sub-process will also need to calculate the price of each item for display purposes.

Business process hierarchies exhibit the following characteristics.

  1. The major processes towards the top of the hierarchy are usually highly specific to a single business domain. Typically, they are complex and long-running – for example, they involve multiple steps that may be separated in time by hours or days.
  2. Any sub-process, sub-sub-process task may make use of any other sub-process in the hierarchy. For example, key business processes may well invoke tasks, initiate actions or raise events. While the chain of command generally runs downwards through the hierarchy, business events frequently trigger the execution of processes at higher levels in the hierarchy.
  3. As you progress lower down the hierarchy, the business activities become simpler and more generic. They also tend to invoke processes that belong to other business domains. The simpler business tasks represent logical units of work that can be performed in a single activity session.
  4. The simplest, leaf-level tasks are generally data related, storing information or changes of status that reflect the outcome of a specific task.
  5. The simpler the task, the more likely it is to be reused by other more complex processes.

In practice, the application of labels like process, sub-process, sub-sub-process etc. is unwieldy. A reusable activity that is a sub-process in one hierarchy might be a task in a different hierarchy. A simpler and more convenient approach is to classify business processes into:

  • task-related activities that perform business logic
  • data-related actions or events that record data or define state-changes

These categories correspond to the top two levels of the Service Layers described on page 143 of SOA Design Patterns.

At a minimum, the Business Analyst should record the following information for each process:

  • the name and business purpose
  • the business domain that owns it
  • how it is initiated (for example, all other processes or business that invoke it, or if it is automatically run at set times or dates)
  • at a conceptual level, what are its inputs and outputs
  • a description of the process internals, including the decision points and sub-processes that are invoked
  • details of any major functional requirements or constraints that need to be met
  • details of any actors involved (such as, humans or systems that perform all or part of the process)

There are three main ways of recording such process details:

  1. As a set of Use Cases, each of which contains this type of information about a specific business process, activity or task
  2. As an interaction diagram that shows the components involved in the execution of a business process together with the messages that flow between these components
  3. NOTE

    The Object Management Group have published a standard business process modeling notation (BPMN, see, for example, http://www.bpmn.org/), and there is a range of software development tools available that can manipulate business process models using a graphical interface and that enforce completeness and integrity of the models they manipulate. Some of these tools have the added advantage of supporting the Business Process Execution Language standard (BPEL) that allows relatively seamless transition from business model to executable code.
    (See, for example, http://www.oasis-open.org/committees/documents.php?wg_abbrev=wsbpel)


  4. As a business process model

The Business Analyst or modeler does not need to start at the top of any logical hierarchy but can start at any level in the process hierarchy where issues have been identified, then progress to higher level processes, or drill down into lower–level processes until the root causes are discovered and a potential solution identified.

Initially, the business process model will define the current way the business performs its activities. To obtain maximum business benefit from the modeling exercise, this should be seen as an opportunity to create future models where the current processes have been simplified, rationalized or enhanced.

NOTE

Creating a comprehensive dynamic business model for any organization is a large and complex activity that should not be undertaken lightly. While production of a complete business model is a strategic goal for any SOA–enabled organization, its development should be considered as an on–going activity that never completely ceases because the organization evolves over time.

There is little or no business justification for creating a complete, purely academic model of any organization, so the business vision, strategy and key investment priorities should be used to define the priority in which the business processes should be analyzed and the depth to which they should be modeled. The prioritized business processes should be modeled only at the level of detail sufficient to establish the principal workflow and major functional requirements at this stage, until they become part of a committed services development plan.



Bottom–Up Business Modeling

An alternative approach to process decomposition is to take a software application that supports an existing business process, and reverse engineer that application into a set of business services. This approach, termed bottom–up modeling, is especially useful for systems integration, where existing applications are restructured or 'wrapped' to expose some or all of their functionality as discrete services.


A Case Study Example

Using the McPherson, Tri–Fold and Alleywood companies popularized by the classic SOA Design Patterns, let's explore service portfolio management in a scenario specific to SOA governance.

Because of the obvious synergy between their efforts, the SOA Governance Program Office (SGPO) has started to build a close working relationship with McPherson Corporation's Strategic Planning team. They meet regularly to discuss their approaches and progress.

In the short term, Strategic Planning wants to focus on restructuring IT throughout the McPherson Corporation and, in the longer term, create one corporate initiative to manage legislative compliance and another to simplify the speed and efficiency of incorporating new subsidiaries into the McPherson empire.

The Strategic Planning team and the SGPO agree that solving the type of problems that have occurred in integrating Alleywood and Tri–Fold are a fundamental pre–requisite to improving McPherson's Mergers and Acquisition process, and that the SGPO should take this as their first priority.

The CIO is a believer in SOA and has championed a services approach to integrate the IT systems of the two subsidiaries that has resulted in the production of a set of 20 or so Web Services that exchange information between Alleywood and Tri–Fold.

However, the McPherson Product Managers have noticed little business impact from the SOA initiative so far. They feel that the service developers are 'bogged down in the details' rather than solving their real business issues and are now pressuring the CIO to make better progress. He asks the SGPO to establish its value by solving this problem for him.

The SGPO sends the lead Business Analyst to investigate. She began by arranging a workshop session with all the McPherson Product Managers to discuss their issues.


  1. Findings at McPherson
  2. The role of the product managers with McPherson Corp. is to manage the supply chain of each product across all subsidiaries that are involved in supplying raw materials, manufacturing, distribution or warehousing. McPherson Product Managers are frustrated that they cannot easily obtain the information they need to optimize the product supply lines, particularly when multiple subsidiaries are involved. They consider that all of the subsidiaries are managing their own individual supply chains effectively but that problems occur when the supply line for a product crosses multiple subsidiaries.

    As a typical example, the Paper Products Manager is particularly vocal in complaining about problems between Tri–Fold and Alleywood. Company policy requires Tri-Fold to use Alleywood as its preferred supplier of wood pulp, but Alleywood is not always able to deliver sufficient quantities of the right grade of product at the time needed, apparently because other customer purchases have reduced the available stocks before they are due to be delivered to Tri–Fold. Since wood pulp is extremely bulky, Tri–Fold cannot stockpile large quantities itself and has to seek alternate suppliers, at short notice and higher cost, to avoid interrupting production.

    The other product managers agree that they have to manage these kinds of problems on almost a daily basis. When the Business Analyst asks them what might help them achieve real integration of the complete supply chains of their paper and timber products, after some discussion, they unanimously agree that their jobs would be far easier if they had instant and complete access to the following information:

    • inventory levels, product by product, of the total quantities currently in stock across the entire McPherson organization
    • The term 'product' is very general; it should include raw materials, saleable goods and waste materials.

    • the business domain that owns it
    • detailed data on how much of that inventory is available for re-distribution and how much has already been committed to meet customer orders or specific production needs
    • the ability to 'drill-down' and see the physical location of each source of inventory and which subsidiary owns it
    • the ability to view the above information over time (for example, to view both historic data and projected levels for the next 3 months or so), which will enable them to predict trends and to balance supply levels

    Currently, they have to try to collate such information using a series of spreadsheets, based on sketchy information obtained by telephone calls to each of the subsidiaries. This is proving very time–consuming and inefficient. Each of the product management groups are spending far too much time and energy 'fighting fires', such as correcting urgent issues that could have been avoided if they had access to the previously outlined information.

    When questioned about the problems of handling compliance with increasingly complex governmental legislation affecting their products, the product managers recognized its importance but considered that finding a solution to it was less urgent than improving their ability to monitor and control production across the entire group.

    The Business Analyst next visits Tri–Fold and Alleywood to investigate their view of the integration issues and to determine if the kind of information the product managers require is actually available.


  3. Findings at Tri–Fold
  4. The trip to Tri–Fold was quite rewarding. Tri-fold did indeed produce most of the necessary information. Their production scheduling process included detailed forecasting of the inventory levels of all the paper and board products for approximately the next four months, and the production schedules for each of their mills were planned 3 months ahead, although they might be adjusted if there was a heavy seasonal demand. This included detailed forecasting of the raw material levels needed by each paper mill.

    The questions the Business Analyst asked about the supply of sawdust, shavings and pulp from Alleywood revealed that unreliability in obtaining supplies of these raw materials was indeed causing major problems. Some improvements had been made when Tri–Fold's IT department gave the production planners access to Alleywood's day–to–day inventory levels of these materials via a web service, giving Tri–Fold some ability to re–order raw materials in advance when the Alleywood supply levels began to run low, but this was only a partial cure.

    The underlying problem appears to be that Alleywood runs its sawdust, pulp and shavings sales on a first come first served or spot market basis, and their processes to manage these items does not provide the ability to maintain a strategic level of reserves to meet long term orders from customers like Tri–Fold who need continuity of supply.


  5. Findings at Alleywood
  6. The trip to Alleywood revealed some interesting issues, mainly in terms of the differences in operating philosophy between the timber and paper industries. The Alleywood Mill operations manager summarized their manufacturing processes as follows:

    In the timber industry, the supply of tree logs is highly seasonal. When timber arrives, the bark is stripped off, the trunks are rough sawn into boards, then laced in storage to season for a period to prevent the boards from warping as the wood dries out. For hardwoods, this seasoning process can take several years. Much of the timber is passed through a kiln drying process to reduce the time required for seasoning.

    These rough sawn boards are taken out of storage when needed for production, then sawn into whatever dimension of lumber that is needed to supply demand. This produces sawdust as a waste product. Some of the lumber is further processed by planning it to produce a smooth finish, producing a fine dust waste product that is suitable for turning directly into wood pulp.

    Bark taken from the tree logs and leftover timber fragments from the sawmills are processed into wood chips, that are either sold to garden centers or used to produce a coarser grade of pulp for cardboard or chipboard manufacture.

    The major difference in philosophy is that the materials that the paper industry sees as raw products are the materials that the timber industry regards as waste products. Alleywood did indeed keep the kind of information on inventory that the McPherson product managers would like to have but only on their core hardwood, softwood, lumber and board products.

    All of the Alleywood management that the Business Analyst spoke to expressed a desire to be good corporate players and help promote better integration into the McPherson Corporation but stressed that the effort of migration to the new Enterprise Resource Planning (ERP) package was currently taking all of their energies.


  7. Analysis and Recommendations
  8. The Business Analyst conferred with colleagues and other members of the SGPO, and the team reached the following conclusions:

    Investigate the feasibility of creating a federated inventory management process to provide both McPherson product managers and the subsidiaries access to current, historical and planned future inventory levels of all products and raw materials of interest to the McPherson group.

    In the immediate term, create a working group of some of the Tri–Fold IT staff and analysts who have familiarity with the new ERP system to work with Alleywood staff to attempt to provide a solution to the wood pulp supply problem.

    Given the current level of SOA resources, the SGPO should defer investigation of the potential for a legislative compliance service in the short to medium term.


  9. Rationale
  10. While most subsidiaries have implemented the same commercial ERP package, these have not been completely integrated at a truly enterprise level. For example, there is a clearly identified need to provide a better solution to enable the McPherson product managers to monitor product and raw material inventory levels across the whole McPherson group. Enabling such corporate monitoring of supply levels should directly support four of McPherson's five key strategic goals:

    • improve the ability of subsidiaries to integrate their individual supply chains
    • improve the ability of McPherson product managers to monitor and control the supply chain process
    • reduce operating costs through better inventory control and diminished reliance on external suppliers
    • create a framework for more structured integration of future acquisitions

    Solving the immediate problem of Tri-Folds raw material supplies would not only help the business as a whole but would also establish the reputation of the SGPO as a practical problem–solving team. The Business Analysts initially created a simplified process model of McPherson's existing manufacturing supply chain process:

    Every month, the McPherson Corp. product managers perform a product sales forecasting process. This updates the monthly forecast of projected sales of each product based on the sales history and marketing plan.

    Using these product sales forecasts, the McPherson product managers then perform a production allocation process that assigns a monthly production quota for each product to one or more subsidiaries. Production quotas for individual products are frozen for up to several months ahead in order to avoid disruptive changes to the supply chain.

    When it receives the updated production quotas, each subsidiary generates a production planning process for each product. In order to optimize manufacturing efficiency, this production planning process includes the following sub-processes:

    • Production Line Optimization Process – ensures that productions runs of each product are as long as possible to minimize the cost of retooling them for individual products
    • Production Warehousing Process – determines the inventory levels of each product that will be maintained each month, so that each month's production quota can be met from a combination of existing and newly-manufactured stock
    • Stock Level Monitoring Process – monitors the physical inventory levels of each finished product and applies incremental adjustments to the production planning process
    • Raw Materials Provisioning Process – forecasts the stock levels of each of the raw ingredients that are needed and that uses the subsidiary's purchasing process to order them from other subsidiaries or external suppliers
    • Waste Products Management Process– minimizes the costs and environmental impact of handling waste materials. Wherever possible, waste materials are sold, recycled, or burnt to provide industrial heating
    • Logistics Management Process–to move physical inventory and raw material levels between production facilities, warehouses and customers

    Modeling a Potential Federated Product Inventory Management Process

    The Business Analyst met with the solution architect and some of McPherson's organization and methods teams to create the outline of a possible future federated inventory management process. They determined that there were two pre–requisite functional requirements to making this process effective:

    1. Since waste materials produced by one subsidiary are the raw materials used by others, the inventory levels of all materials produced or consumed by any subsidiary should be subject to the same inventory management processes, whether they are raw materials, finished products or commercial waste.
    2. All McPherson Corp. subsidiaries must have the ability to reserve inventory in order to fulfill customer orders with a specified future delivery date (for example, any inventory should be divided into stocks that are available for sale and stocks that are reserved because they are committed to customer orders at a future date). Customers who are also subsidiaries are to be given priority when placing orders for immediate or future delivery.

    The team created a simple interaction diagram of how a federated inventory might work in practice, shown in Figure 2.

    A federated inventory management process would provide a global view of inventory levels of all materials of interest to any McPherson subsidiary. The McPherson product planners could query the federated inventory management system for the available inventory of any product. The federated inventory management system would query the inventory management processes of each subsidiary for their individual levels and return the totals available across the organization.

    The various inventory management systems can also be extended to show future planned availability levels – for example, the available quantity of any product throughout the entire corporation for a specific future date.



    Figure 2 – A Federated Product Inventory sequence.

    The team also analyzed the effect that implementing a federated product inventory management process might have on the overall supply chain, giving specific focus to improving the estimation and handling of raw materials.

    They came to the conclusion that the kind of problems that had been occurring between Tri–Fold and Alleywood could be eliminated through:

    1. Reserving raw materials such as pulp and chippings produced by each company against known future requirements of other subsidiaries. This allows both the supplier and consumer of these materials to forward a plan to avoid supply bottlenecks.
    2. When there is a predicted shortfall in raw materials availability, attempting to meet that shortfall by sourcing it from another subsidiary or adjusting the output of the manufacturing processes that produce it, before ordering it from a competitor.

    The team came up with the following model:



    Figure 3 – Improved iterative enterprise resource management using a federated approach.


Conclusion

The next article will conclude this series with an exploration of building static models of business entities and various topics relevant to building your own custom service portfolio.