Export (0) Print
Expand All

Northern Electronics Scenario: Supporting Business Operations Requirements in the IT Organization

 

Max Morris
with Frederick Chong, Jim Clark, and Dave Welsh

September 2005

Applies to:
   Enterprise Architecture
   Solution Architecture
   Service Oriented Architecture (SOA)
   Service Oriented Management (SOM)
   Application Integration
   Business Process
   Business Operations Modeling

Summary: The Architecture Chronicles on Dynamic Modeling: Aligning Business and IT seek to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. Using the story of how Northern Electronics works with its business partners to improve its product shipping process, the authors discuss a systematic approach to formalizing information from many domains into reusable, structured, and connected models, demonstrating business operations and IT operations can increase their communication with each other, resulting in improved business performance and stronger partner relationships. (27 printed pages)

Contents

This Document
Abstract
Acknowledgments
Introduction
Scenario Background
Modeling the Product Shipping Activities
Business Operations Requirements of Product Shipping
Building the Product Shipping Solution
Conclusion

This Document

This document is part of the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT. This volume seeks to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. The information map to the series provides an up-to-date description and cross-index of the information available and can be found at the Microsoft Architecture Resource Center.

Abstract

Making sure business operations are working well across organizational boundaries is a hard challenge. But it is an increasingly important one to address in today's connected world. A key to success in meeting this challenge is making sure the business and IT operations teams within an organization are well connected. A thorough discussion of a real-world business problem helps highlight the issues involved in making these connections and meeting this challenge. Particularly, the discussion shows how supporting business operations requirements in the IT organization can play an important role in the solution.

Acknowledgments

Many thanks to Nelly Delgado for her help with technical writing, Claudette Siroky for her graphics skills, and to Tina Burden McGrayne for her copy editing.

The authors would also like to thank Gajanan Phadke, Vishal Kapoor, Amol Wankhede, Aziz Matheranwala, Amit Kumar Srivastav, Bhushan Pawade, Bhasha Johari, Avadh Jain, Mughda Gadre, Maneesha Nalawade,Sonika Arora, Anil Sharma, and Anurag Katre (all of Tata Consulting Services) for their contributions to the implementation of the Northern Electronics solution.

The authors would also like to thank Klaus-Dieter Naujok and Allyson Winter (of Global e-Business Advisory Council) for their contributions to the development and documentation of the proof-of-concept business operations modeling worksheet tool used to illustrate this document.

Introduction

This document follows the story of how Northern Electronics works with its business partners to improve its product shipping process. The scenario and discussion are designed and organized to illustrate common characteristics of how businesses deal with each other in a value chain. The scenario is described in a narrative fashion, focusing on a single example throughout to highlight key challenges and possible solutions people and technology encounter when trying to meet business operations requirements with IT solutions. The discussion makes the argument that by following a systematic approach of formalizing information from many domains into reusable, structured, and connected models, business operations and IT operations can increase their communication with each other and thereby achieve better performance internally and with their business partners. An important use of this increased communication is in the effective and timely management of business activities and business exceptions that occur within the IT domain.

More detailed information on achieving operational agility by aligning business and IT can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Also, throughout this document, other documents in the series that rely on the Northern Electronics scenario are noted. These other documents use the scenario to examine in more detail from a variety of perspectives how to align business and IT through dynamic modeling.

Scenario Background

Northern Electronics is an electronics maker based in Everett, Washington, with a partly-owned manufacturing subsidiary based in Nanjing, China.

The company operates in an increasingly difficult market, facing nimble, global competitors and a demand from customers for flexibility to deliver a wider variety of products more efficiently. The executives have concluded that possessing a distinct competitive advantage relative to their competition in how agile they are able to manage their value chain is critical to the company's increased profitability. In practical terms, this translates into a need to identify and capitalize on opportunities to consolidate and automate business activities within their value chain.

In stepping up to this challenge, the executives decided not to go about restructuring their business activities in a top-down fashion. They determined that such an approach would be too disruptive to existing processes and potentially the business as a whole. The approach also seemed too impractical to coordinate. The bottom-up approach was also rejected, primarily because they determined that setting a goal and hoping it would simply happen was too wishful—they wanted to see results.

Instead, the executives decided to take a middle-out approach in implementing their strategy of change. At the executive level they set clear goals and communicated widely the need, support, and rewards for projects that improve the value chain efficiency. In turn, they became opportunistic about proactively initiating projects that they believed in, and in supporting ones that emerged independently from the various business units.

Product Pickup and Delivery at Northern Electronics

The order fulfillment department at Northern Electronics coordinates the pickup and delivery activities around getting an ordered product to a customer. These activities include verifying and validating purchase orders (POs) with the sales department, verifying credit with the accounting department, coordinating inventory management with the production department across the various warehouses, managing the transport of products to customers, and updating delivery status for the accounts receivable department.

Within the transport function, product shipping is an area that the company has had problems with. Product shipping involves significant coordination, including ordering transport from the right consolidator, moving the right product in the right amount from the right warehouse to the right loading dock, and getting the waiting product onto the right truck. That truck must be driven by the right trucker and arrive at the right time as an agent from the right consolidator.

Product shipping is a core business process for Northern Electronics. Businesses expect problems to arise and have procedures in place to handle them. In some cases, the consequences can amount to just a marginal impact, because the exception can be managed easily or simply accommodated. In other cases, the consequences can be severe and can lead to financial penalties or even loss of business. From the perspective of the warehouse, problems such as the truck not arriving on time, a truck arriving but being the wrong truck, or the truck being too full to accommodate the order can occur. From the perspective of the customer, problems such as non-delivery of product, incorrect delivery of product (the wrong product or the wrong amount of product), or delayed delivery of product can occur.

With good up-front planning and experience to draw on, the difficulty in handling exceptions at the business level isn't in knowing what to do about them. Most issues can be anticipated, and a good plan will include some way of dealing with the completely unexpected. Instead, the difficulty in exception handling is mostly about getting useful information about an exception that has occurred to the right person in time, or even ahead of time, so that he or she can do something about the problem as it happens—or before it happens. When the right information arrives to the right person in time, there's a better chance that whatever intervention the person can implement can have a more significant mitigating effect. When this doesn't happen, the single, unresolved problem can cause a cascade of other problems, soon bringing the coordination of the activities to a halt. Figuring out what has gone wrong and where, and getting things back on track (if that is even possible), can take a lot of time, energy, and expense.

Making a Change in Product Shipping

The company has had ongoing problems with the product shipping process. Trucks don't always arrive on time. And even when they do, the requirements for the truck aren't always met. Also, the wrong cargo shows up at the loading dock more often than it should. All of these logistical problems result in much higher overhead costs, and especially, in delay for the customers expecting on-time arrival.

Product shipping is an area that Northern Electronics has decided to improve. The company has decided to tackle two aspects of the product shipping process:

Achieve more efficient coordination in product shipping with business partners.

Achieve more efficient handling of business exceptions in product shipping when they occur.

Let's take a look at the corporate structure of Northern Electronics and review the individuals who will be involved in improving the product shipping process.

ms954614.msarcseriesmcs01(en-us,MSDN.10).gif

Figure 1. Some of the Northern Electronics employees involved in product shipping

Barbara is the head of Business Operations and reports to the COO. It was her initial investigation of the product shipping process that led to a proposal to improve it. The COO has approved Barbara's proposal, so she is moving forward with her team to carry out the project. Barbara assigns Pam, a program manager on her team, to carry out the day-to-day work. Zack is the head of IT Architecture who reports to Sara, the CIO. Zack is assigned overall responsibility of working with Barbara and Pam to implement the IT components of the improved solution. Zack is responsible for the overall design of the software solution, working with Pam to meet the business operations requirements and Jackie to coordinate implementation. Jackie is a program manager on the IT side who works for Zack. Jackie manages the implementation of the project and works primarily with Tom, the solution architect; Sam, the lead developer; Kim, the test lead; and Dan, the application support analyst.

Modeling the Product Shipping Activities

As Pam gets to work, her first decision is that she must get a handle on understanding the product shipping process. She decides the best way to do this is to pull together a formal description of the existing processes in product pickup and delivery, so she can better determine what the problems with product shipping are and where changes should be made. In a sense, she begins an effort to formally model how product shipping is done.

Understanding Product Shipping

To understand the domain, Pam interviews a number of experts within Northern Electronics and related third parties including the individuals in the following roles:

  • The business analyst provides business knowledge about product shipping, including what data needs to be collected and how it should be manipulated to reflect the physical reality. This includes requirements for handling and packaging the goods, requirements for third-party transport services, and shipping schedules.
  • The financial analyst provides the financial plan regarding the shipping budget, customs charges, any other taxes, freight rates (tariffs), and insurance rates.
  • The shipping manager supervises logistics and enforces any regulatory requirements.
  • The consolidator is a third party who provides input regarding requirements for packaging, delivery options, scheduling, and relevant forms.
  • The attorney provides guidance on industry standards and regulations that are best practices and legal requirements for product shipping.

It's especially important to note that not all of these individuals work at Northern Electronics. For example, the consolidator is a third-party company that Northern Electronics does a lot of business with. Getting improvements in the product shipping process is not something Northern Electronics can do alone—it involves the entire value chain, as will be shown more clearly later in this document.

Through Pam's interactions with these individuals and from market and regulatory information, Pam begins to develop a good model for how the product shipping process works.

An example of the broader product pickup and delivery process, namely how a product moves from the manufacturing floor to a customer's facility, that the product shipping process is a part of helps illustrate Pam's findings. Figure 2 describes the high-level business entities involved in the larger product pickup and delivery process. (The entities in this example will be used in the discussion through the rest of this document.)

Some of Northern Electronics's products are manufactured at their plant in China and then shipped to their warehouse in Everett. One such product line is the electronic controller for remote-controlled airplanes. One of Northern Electronics's customers is a wholesaler named Wingtip Toys that assembles remote-controlled airplanes in Dallas, Texas, and then sells the airplanes to retail companies. Northern Electronics hires Acme Consolidation Company, a freight consolidator based in Portland, Oregon, to arrange the transport of the electronic controllers from the warehouse in Everett to the wholesaler's warehouse in Dallas.

Acme Consolidation Company performs many tasks, including:

  • Collecting the appropriate paperwork from Northern Electronics.
  • Providing the freight cost.
  • Reserving space for freight with freight companies and coordinating with the freight companies to deliver the cargo to the destination warehouse.
  • Offering Northern Electronics insurance for the cargo while in transit.

In this example, Acme Consolidation Company hires Blue Yonder Truckers, a local trucking company to pick up and transport the goods.

ms954614.msarcseriesmcs02(en-us,MSDN.10).gif

Figure 2. Entities involved in the product pickup and delivery example

Pam learns that whenever Wingtip Toys wants to place an order with Northern Electronics, the purchasing agent at Wingtip Toys calls Northern Electronics's sales agent. Pam listens in on the initial phone call and notes the following:

  1. The purchasing agent at Wingtip Toys, Frank, tells the sales agent at Northern Electronics, Koji, that he needs 1,800 controllers.
  2. Koji tells Frank his cost will be $17,316 ($9.62 per piece) plus shipping and handling charges.
  3. Frank doesn't immediately accept the offer.
  4. Frank talks to his boss and his boss asks Frank to try to get a lower price.
  5. Frank calls Koji back and says that the most he can pay is $5.25 per piece. "Perhaps if you increase your order number," Koji replies.
  6. Frank agrees to increase the order number to 4,000 controllers.
  7. Koji talks to his boss and they decide they can give Wingtip Toys each piece for $6.74.
  8. When Koji lets Frank know of the new price, Frank says, "Okay, but only if you give me free shipping and handling."
  9. Koji and Frank agree on the total price of $29,960 for 4,000 controllers plus free shipping and handling.
  10. Koji then collects the information and lets Frank know his order will arrive in 6 – 8 weeks.
  11. Koji then faxes the order information to Frank.
  12. Koji writes down the purchase order (PO) details, which include the PO number, wholesaler name, wholesaler address, product code, number of items ordered, expected day (and time not before), expected day (and time not after), and order status.

From this exchange and others like it, Pam is able to determine that the product shipping business process, as a narrower part of the broader product pickup and delivery process, begins when a PO is created. A business process is composed of a business activity or set of business activities conducted to achieve a business goal or objective. Here, the objective is to deliver an ordered product to the customer.

In talking to the business analyst, Pam learns that Northern Electronics collaborates with other parties, namely the freight consolidation company and the transport company, to fulfill the activities in the product shipping business process. Therefore, Pam determines that she is really documenting a specific type of business process, namely a business collaboration. A business collaboration is a set of activities involving two or more parties to achieve a business goal or objective. In fact, she realizes that the higher-level product pickup and delivery

In the case of the example, Pam determines that the product shipping business collaboration works like this today:

  1. Richard, the shipping clerk at Northern Electronics gets new POs on his desk every morning. One of his daily tasks is to verify that the warehouse has the items in stock. If the items are not in stock, Richard notifies the customer that the PO is backordered. The PO is placed in a "Waiting for Goods to Arrive" backorder pile.
  2. When Richard knows that he has the goods in stock, he performs a stock allocation to cover the order. He calls Julie, the transport consolidator clerk at Acme Consolidation Company, to arrange the delivery of the goods to Wingtip Toys. Julie was on her lunch break when he called, so he left her a voice mail and put the PO into the "Pending" pile. When she gets back from lunch, she calls him back to get the details. Because Richard has a lot of piles on his desk, it takes him a few minutes to locate the PO he needs. He finally finds the PO and lets her know what the requirements are. Julie considers these, and then she agrees to transport the goods. Richard then writes up a new transport order request and puts the PO into the "In Progress" pile. He updates and gives the pickup list to David, the loading dock clerk, to get the required number of items of the product from the warehouse and arrange for the packaging of the goods, including putting the items on pallets, shrink-wrapping them, and labeling the package.
  3. Julie has a pool of trucking companies that she calls. She goes down the list to order a truck that can drive the shipment from Everett, Washington, to Dallas, Texas. She finally finds one that can do the job. Blue Yonder Truckers can arrive on the following Tuesday at 10:00 A.M. to load the truck. The clerk at Blue Yonder Truckers gives Julie the license number of the truck and she sends the transport order details to the trucker. Julie also faxes Richard a transport notification form with the specific details of the truck.
  4. Richard keeps track of the scheduling of when packages are supposed to be picked up and makes sure the goods are ready to be loaded onto the dock when the truck arrives. He has a schedule of the pickups on the white board in his office and writes down the new request.
  5. On the morning of the scheduled pickup, Bob, the trucker, checks in with Richard at 10:05 A.M. Richard pulls up the order and checks Bob's paperwork. He notes the time of arrival and tells Bob which loading dock he should pull his truck to.
  6. Bob pulls his truck up to the correct loading dock. David asks Bob for the paperwork and loads the packaged and labeled order on the truck. Bob counts the items to verify it's the same number as the number on the paperwork. David enters the final load weight into the transportation documentation and Bob signs the paperwork, assuming liability during transportation of the goods. When Bob drives away, David notes and enters the time and gives a copy of the paperwork to Richard.
  7. Richard gets the documents and faxes the information to both Wingtip Toys and Acme Consolidation Company to let them know that the trucker has picked up the shipment. He then updates the PO and places both the PO and transport order documents into the "In Progress" pile.
  8. When the truck arrives at the customer's warehouse, the customer faxes a confirmation of the arrival to Richard. He then places the PO and transport order into the "Completed" pile.

While all of the shipping is happening, Northern Electronics invoices Wingtips Toys, and Acme Consolidation Company invoices Northern Electronics.

Pam models the information flow around the product shipping business collaboration by using a flow chart, as shown in Figure 3.

ms954614.msarcseriesmcs03(en-us,MSDN.10).gif

Figure 3. Product shipping business collaboration information flow

As Barbara observed in her original proposal to improve product shipping, Pam can see now more specifically that many of the processes surrounding the product shipping business collaboration are dependent on human interaction and manual processes. There is information that is transmitted over the phone, paperwork that is manually filled out, faxes that are sent and received, and paperwork that is manually handed from one person to another. Pam wonders how often a message is not received or a piece of paperwork gets lost. This must certainly waste the employees' time, waste the company's money, and cause a lot of frustration for everyone involved. Moreover, how well can this process scale when the company starts to grow, or as it tries to be more competitive? How many more employees are going to need to be hired and trained to process paperwork and answer phone calls? Ultimately, the concern is: What is the impact to the customer and customer service?

Pam recognizes that some aspects of product shipping will still need to be manual but other parts of the process can certainly be automated. Pam works with Zack to identify the areas that can be automated.

Pam and Zack decide that they need to identify discrete business services that make up the product shipping business collaboration. A business service is a set of offered business actions for the purposes of achieving a business objective.

Automating business services in the product shipping business collaboration, where possible, should provide the means for better communication, coordination, and collaboration between Northern Electronics and its business partners. Automating business services should help Northern Electronics to:

  • Manage for business performance.
  • Stipulate authorized business rules.
  • Obtain real-time business intelligence through key performance indicators.
  • Ensure the services are designed for reusability and scalability.

One significant source of improvement from automated business services should be the ability of Northern Electronics to be in better synchronization with its business partners involved in the product shipping business collaboration. As noted earlier, one major problem area in product shipping is dealing with exceptions in a timely and effective way. The challenge in exception handling is mostly about getting useful information about an exception that has occurred to the right person in time, or even ahead of time, so that he or she can do something about the problem as it happens—or before it happens. When the right information arrives to the right person in time, there's a better chance that whatever intervention the person can implement can have a more significant mitigating effect.

Pam interviews Richard and asks him, "What are the key things in product shipping that you worry about?" He lets her know there are key events that must happen for the product shipping process to flow smoothly. The most important are:

  • The truck must arrive on the correct day within the specified period of time. The pickup time is Monday through Friday from 10:00 A.M. to 10:30 A.M. If the trucker does not arrive within the designated time, the trucker will need to pick up the goods on the next business day.
  • The truck must be the right truck. This means that the truck must have the correct license plate number as agreed in the paperwork, must be the right size, must be insured, must have the right trucking permits, and must be in good working condition.
  • The truck driver must be the right trucker. The truck driver must have the correct paperwork containing the shipping reference number allocated by Northern Electronics.
  • The loading dock must be ready with the goods when the truck arrives.
  • The truck must depart with the shipment loaded within the specified period of time.

    In the event that one (or more) of these conditions is not met, the process will be delayed. In the worst case, one delay can have a snowball effect and delay other shipments as well. This will severely and negatively affect the business.

    Pam talks to Zack to find out whether some of these key events can be managed with IT infrastructure. Pam reasons that if Richard can get an advanced warning before one or more of these conditions are not met, it can help them plan for the situation before it becomes a problem.

Formalizing the Product Shipping Business Collaboration

Pam's investigations into how product shipping works at Northern Electronics have made her the expert. She has put a lot of organization into arranging the information she has collected, much of which came from many different sources. But still, only she really has the full picture of what is happening. The challenge is that many other people within Northern Electronics (and Acme Consolidation Company) need to know some or all of the details about how the process works and where she wants to improve it. It is important for Pam to formally capture the information in such a way that she can put context onto how the information is interrelated. To do this, Pam uses a business process modeling approach.

Pam recalls that a business process is composed of a business activity or set of business activities conducted to achieve a business goal or objective. To model the business process, she must classify the participants and describe what they are doing. She starts with Northern Electronics, which she identifies as a participant in the product shipping business process. The product shipping business process begins when a PO is created and it ends when the package is put on the delivery truck. There are many business activities that happen in between. Pam visualizes the model of this information as shown in Figure 4.

ms954614.msarcseriesmcs04(en-us,MSDN.10).gif

Figure 4. Product shipping business process

Pam realizes that the model visualization in Figure 4 doesn't capture the detail she needs to express. As she determined earlier, what Pam is trying to describe is the activities that Northern Electronics and its business partners jointly care about in making sure the product shipping process happens. It's when these activities don't go as planned that Northern Electronics, or one of its business partners, begins to experience the kind of problems that have led to high costs. Instead of modeling product shipping as a business process that's just about Northern Electronics, Pam needs to model product shipping as a business collaboration that includes the involved business partners.

Pam writes down the business activities conducted within the product shipping business collaboration as shown in Figure 5.

ms954614.msarcseriesmcs05(en-us,MSDN.10).gif

Figure 5. Product shipping business collaboration and related collaborations

The product shipping business collaboration with Acme Consolidation Company is shown in Figure 5.2. Pam knows that as part of the end-to-end example she's been looking at, Northern Electronics also has a business collaboration with Wingtip Toys, namely in ordering the product in the first place, as shown in Figure 5. Pam also knows through her work with her business partners that Acme Consolidation Company has a business collaboration with its freight company, Blue Yonder Truckers, as shown in Figure 5.4. Some of the business activities in that business collaboration operate in parallel with the product shipping business collaboration, but Pam doesn't have to worry about those because she is treating Blue Yonder Truckers as Acme Consolidation Company's agent.

For the purposes of product shipping, Pam is only concerned with the product shipping business collaboration, and in the example, that only involves Northern Electronics and Acme Consolidation Company.

Now that she's looked at the entities as a whole, Pam wants to better understand the business collaboration by identifying the following actors in the scenario and their responsibilities:

  • The supplier shipping clerk receives new POs and verifies that the warehouse has the items in stock. The clerk is responsible for ordering the necessary transportation for delivering goods to the wholesaler. The clerk is responsible for verifying that the details in the transport notification satisfy the conditions in the requests or take corrective actions if necessary. The clerk arranges for the packaging of the product and is responsible for preparing the loading dock with the goods to be shipped. The clerk uses a pickup scheduling application to determine the PO that has an associated transport notification. The goods are then queued in first-in, first-out order at the loading dock.
  • The transport consolidator clerk is responsible for processing the transport requests coming from the supplier. The clerk will research with the contracted trucking companies to find available transport for their supplier client. After the transport provider is identified, the clerk fills up a transport notification form and sends it to the supplier.
  • The trucker is responsible for picking up the goods from the supplier. On the day of pickup, the trucker arrives at the designated time and checks in. When the loading is completed, the trucker signs a pickup completion form to transfer and assume liability of the goods in transit.
  • The supplier loading dock clerk prepares the final transportation document that contains the pickup details. Upon completion of loading, the clerk sends the document to the transport consolidator to confirm the goods pickup.

Pam uses an activity diagram to document the business activities in the product shipping business collaboration as shown in Figure 6.

ms954614.msarcseriesmcs06(en-us,MSDN.10).gif

Figure 6. Product shipping business collaboration activity diagram

Some of the business activities are internal activities only relevant to Northern Electronics. However, other business activities rely on a successful collaboration between Northern Electronics and Acme Consolidation Company.

Business Operations Requirements of Product Shipping

Now that Pam has a firm understanding of how product shipping works in the business environment, she needs to translate the information into something that the IT organization can use to design, implement, and operate a solution. Particularly, Pam wants to make sure that the IT solution is set up and operated in such a way that it can help detect and correct any business exceptions that will occur when the product shipping business collaboration operates.

Pam uses the information she has collected and works with Mark, a business analyst, to enter the information into a business operations modeling tool. The specific kind tool they use employs a set of worksheets to capture information about a business collaboration. Similar to how complex tax law lies behind tax forms, behind these worksheets is a pre-defined, interrelated, formal structure of information that corresponds to the things that happen in business collaborations. Because Pam's business collaboration is quite typical, using a worksheets modeling tool is a convenient and sufficient way of ordering the information she has collected.

The value of the business operations modeling tool they use lies in its ability to transform the information after it has been entered into a form useful for IT. Because the tool is designed around the idea of business collaborations, it is able to select and relate connections in the data that aren't obvious to the business analyst. The tool is also able to transform the structure of those relationships into other structures that are much easier for IT architects, programmers, and operators to work with.

Specifically, this kind of tool enables Pam to:

  • Capture the formal definition of the business collaboration into an electronic form.
  • Derive a business operations specification that describes the overall business collaboration, including the business documents exchanged between the parties in the business collaboration and the semantics of those exchanges. The specification can be used by the IT staff to help guide both design and implementation.
  • Derive a business operations specification that describes the critical business exceptions to manage for in the business collaboration, as well as the potential corrections that can be made. The specification can be used by the IT staff to help guide design, implementation, and operations.

An example of a user interface of the kind of tool Pam uses is shown in Figure 7.

ms954614.msarcseriesmcs07(en-us,MSDN.10).gif

Figure 7. A business collaboration modeling tool capturing information about product shipping

Pam is able to use the specifications to communicate her requirements to Zack and the rest of his team in the IT organization in a way that relates to the kind of work they do.

Particularly, the business operations specification that specifies management requirements helps Zack know which management functions need to be set up to support the business operations requirements as he and his team design the system. The system infrastructure will need to be set up and configured so that appropriate business activities can be managed or logged. The business operations specifications present requirements to IT in a way that can be used to create a business operations health model. A business operations health model is a specification of the detection, verification, diagnostic, resolution, and re-verification actions for any manageable condition in a business collaboration. Of course, not all business exceptions are predictable, and not all manageable conditions are business exceptions. But business exceptions already known to impact the business collaboration negatively are contained in the information Pam has collected. The information also contains requirements for other manageable conditions, such as logging certain activities that occur to produce an evidentiary record. The business operations specifications pull these manageable conditions out of the formal business collaboration model and present them in a way that Zack and the rest of the IT organization can work with.

An example of such a manageable condition from the product shipping business collaboration that Northern Electronics wants to pay close attention to has to do with the on-time arrival of the trucks. The business operations specifications call out this requirement formally:

  • Business Operations Requirement (BOR): The truck shall arrive to pick up the goods at the supplier's warehouse on or before the specified SuggestedPickupTime.

    Two tables describe the details around this business operations requirement.

    Table 1. Business Operations Health Model ( Detection Information)

    ProblemHealth State and Operational ConditionIndicatorsOperational AlertsCriticality
    Violation of BORDegraded; Integrity ProblemEvent (ID = EVENT_TRUCK_ARRIVAL_DELAYED)

    This event is logged to the event log.

    An e-mail notification will be sent to the Business Operations Managers notification group.An event processing rule generates an alert with the severity set to Severe.

    Table 2. Business Operations Health Model ( Verification, Diagnostic, Resolution, and Re-verification Information)

    ProblemVerification ProcedureDiagnostic InformationResolution and Final Desired StateRe-verification
    Violation of BORManual check that truck has not arrived (should return TRUE). Operational condition confirmed as integrity problem.Manual check. Call to transport consolidator to find out where truck is.Manual resolution. Supplier renegotiates truck arrival time with consolidation company and updates the time in the system. Supplier updates SuggestedPickupTime. The logs and databases are both updated with new information.Manual check that truck has not arrived (should return FALSE).

Table 1 shows how to detect the condition (in this case, a business exception) and Table 2 shows how to proceed after the detection has been made. The final resolution in this case from the IT domain is just to provide feedback to the business operations managers. No control action by the IT management system is needed to change the state of the system.

More detailed information on communicating business operations requirements to IT using business operations modeling can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Building the Product Shipping Solution

With the business operations requirements well documented in specifications, and with a good line of communication between him and the business operations team, Zack is able to move forward with his team on the design, implementation, and roll-out of the IT solution.

Zack's team works differently from Pam's. Just as there is a program manager in the business realm, there is also a program manager on the IT side working under the guidance of Zack. Her name is Jackie.

The work now is to design, implement, and build out the infrastructure in the IT domain that supports the product shipping business collaboration. Jackie takes the requirements contained in the business operations specifications as a starting point and begins to build a plan for meeting them. Throughout the course of the project, she monitors the project status and works with the following individuals who have the noted skills and tasks:

  • Tom. He is the Solution Architect, provides the technical knowledge and drives the actual solution design. Tom understands how different business systems work together. He understands technology capabilities and its limitations. He communicates with business system analysts to understand the business functions that need to be supported and built and the desired business user experience. He creates and communicates the application design to the software developers and assigns tasks to the project. He is also responsible for determining software development methodologies and tools.
  • Sam. He is the Lead Developer, develops the software to meet the functional and non-functional requirements. Sam writes and runs unit tests, runs code analysis, writes load tests, and checks in work. When any bugs are reported, Sam diagnoses and fixes the bugs, and checks in the work.
  • Kim. She is the Test Lead, generates test cases for the application. She checks the build status, loads and runs tests, and reports bugs.
  • Dan. He is the Application Administrator, understands the capabilities and constraints of the server and network infrastructure. Dan works with solutions architects to understand application design and communicate necessary operational requirements into the application design and development. Dan uses operational tools to codify operational requirements into management scripts for monitoring and automated tasks. He deploys the application on the appropriate computers. He also troubleshoots and fixes advance operation faults.
  • Craig. He is the Application Support Analyst, monitors the performance and health of the services. He troubleshoots and fixes basic operation faults.

Zack's team uses the service life cycle approach shown in Figure 8 to work together to meet the business operations requirements.

ms954614.msarcseriesmcs2f08(en-us,MSDN.10).gif

Figure 8. Using the service life cycle

The service life cycle approach helps the team:

  • Consider the non-functional attributes that allow services to be operated, maintained, and upgraded over the course of time.
  • Identify the roles involved in the service life cycle and derive management tasks that each role performs.
  • Describe the conceptual elements and constraints of the management tasks using a collection of management models.
  • Build solutions for the management models using products and technologies. The resulting tools and applications are tailored to meet the needs of the individual roles in the organization.

More detailed information on issues in aligning business and IT through dynamic modeling, the service life cycle approach, and IT systems management can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Design Phase

Tom's primary responsibility as the architect is to design the solution. To do that, he considers:

  • The business operations requirements as provided in specifications by Pam and Zack.
  • The non-functional attributes that enable services to be operated, maintained, and upgraded over the course of time.

Tom analyzes the business operations specifications that Pam and Zack have given him as well as IT organizational policies to create a design for the solution. He focuses on two areas of design, the Web service solution design and the Web service health model.

Tom considers many issues as he develops his design:

  • Service metadata:
    • Service configuration (system and network parameters).
    • Message security policies and business rules.
  • Identities and entitlements.
  • Service composition.
  • Roles of directory services:
    • Managing security data (credentials and entitlements).
    • Managing service configuration and policies.
  • Consistency with infrastructure.
  • Operational processes.

Tom follows a model-driven development approach that uses highly structured information models to capture the intentions and desired results of stakeholders like Pam and Zack. In terms of the business operations requirements in particular, this approach ensures that Tom proactively thinks about the instrumentation and tasks required to achieve the desired consequences; he also thinks about actions for the mitigation strategies in the event of business exceptions.

Web Service Solution Design: Business Services to Web Services

Tom's design approach is to rely on Web services to implement automatable business services within the product shipping business collaboration. Tom expects that some of the Web services will be internal to Northern Electronics, while others will be used directly by business partners.

Tom works with Pam and Zack to identify candidate Web services for the product shipping business collaboration. They review the way shipping is currently done while thinking about what can be improved through automation. Pam and Zack already considered this question from the business perspective when they looked at the business services involved in product shipping. While the business operations specifications capture the detail of that analysis in a formal way, Tom needs the consultation with Pam and Zack to help him get a thorough understanding of what is happening and why the specifications have the requirements they do.

One example of something they review together has to do with when the product shipping business collaboration begins. The negotiation between customers and Northern Electronics is done verbally, usually over the phone. This is outside the scope of the product shipping business collaboration. Moreover, the negotiation is not a good candidate for something that can be automated because the human interaction is probably a necessary aspect of negotiating the purchase. The starting point of the product shipping business collaboration is when the PO is created. The PO is an artifact that can be stored electronically instead of on paper.

Another example of something they review together is the ordering of transport. After the PO is created, the supplier shipping clerk checks to make sure the items are in stock. If the items are in stock, the supplier shipping clerk works with the transport consolidation clerk to coordinate the transport that will pick up the shipment and deliver it to the customer.

Yet another example of something they review together is the security requirements. Identities of the participants in the business collaboration must be represented as digital identities in the Web services domain. The processes of authentication and authorization are necessary to control access, usage, and administration of the services, especially across administrative boundaries—in this case, between the supplier and the transport consolidator. Tom has to make sure he understands issues such as who has the authority to create or change transport order information and who can confirm acceptance of transport. These issues are especially important to meet the business operations requirements, which outline strict legal requirements. For example, they specify the role of who in Northern Electronics is actually allowed to order transport from a transport consolidator (and therefore commit the company to payment for the ordered transport). (Other requirements related to security and identity, such as logging specific activities as they are performed by certain roles, are expressed in the business operations specifications.)

Tom agrees with the conclusion from Pam and Zack that the interactions between the supplier and transport consolidator are good candidates for being automated and implemented using Web services. He reasons that:

If the transport consolidator has a Web service the supplier shipping clerk can use to send his request to, instead of relying on a phone call, it is unlikely the request will get lost. The supplier shipping clerk can also get proof that the request was received. The transport consolidation clerk can then process the request and generate an acceptance.

If the supplier has a Web service the transport consolidator can use to send his acceptance of the transport order to, instead of relying on a fax machine, it is similarly unlikely the request will get lost. The acceptance can contain the details and terms of the product pickup. The transport consolidation clerk can get proof that the acceptance was received and thereby that the terms were agreed to.

After Tom examines the business collaboration further, he reasons that the supplier shipping clerk and loading dock clerk can work more efficiently by using an internal Web service to let them know about the shipments that need to be loaded onto the docks in the correct order based on the trucker's expected time of arrival. They can use this internal Web service to record the trucker's credentials and can also use it to confirm that the shipment was picked up. In turn, the internal Web service can then automatically send a pickup confirmation to Acme Consolidation Company's Web service.

Based on this analysis, to meet the requirements laid out in the business operations specifications and to create the internal efficiencies he identified, Tom proposes a design that includes three Web services to facilitate the product shipping business collaboration:

  • ShippingService Web Service. This is the supplier's Web service used to send and receive the details of the shipment pickup.
  • PickupService Web Service. This is the supplier's Web service used internally to be notified of product pickup and to confirm the shipment was picked up.
  • TransportService Web Service. This is the transport consolidator's Web service used by the supplier to initially order the transport and finally to confirm that the shipment was picked up.
  • Obviously, the TransportService Web service is not something that Northern Electronics can implement, because it belongs to the transport consolidator. But it is a needed part of Tom's design.
  • Tom works with Zack and Pam to coordinate the development of the TransportService Web service with the chosen transport consolidator business partner, Acme Consolidation Company. If the approach proves successful, Pam and her team can organize similar coordination with other transport consolidation business partners.
    Note   The coordination with Acme Consolidation Company is outside the scope of this discussion, which simply relies on the coordination happening successfully.
  • Tom uses the business operations specifications to define the actual interfaces of the Web services.
  • More detailed information on Web service solution design can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Web Service Health Model: Designing for Operations

The proposed three Web services allow messages to be sent and received in a systematic and verifiable manner. In addition to satisfying the business operations interface requirements, Tom also needs to think about how service instrumentation can be used to provide visibility and control over running instances of Web services. Web service instrumentation may take the following forms:

  • Debugging traces can help with diagnosing code execution behaviors.
  • Events are used to raise alerts that signify meeting certain management conditions.
  • Performance counters are used to generate statistics that reflect the health of the services.
  • Probes are internal service states that can be queried and controlled by management applications.

Tom needs to make sure the two Web services that Northern Electronics will implement can be designed for operations. This means that the Web services need to be designed to be managed to meet their performance objectives at multiple levels.

The IT organization uses a health modeling approach to develop a thorough understanding of how the Web services should perform, how to learn about how they are performing, and what to do when they are not performing according to plan.

Health modeling is a process within the design phase of the service life cycle to formally document the understanding of the system designers about what a healthy system is and what an unhealthy system is. It considers in advance all the manageable conditions the designers can anticipate. The health model that results contains detailed consideration of each anticipated manageable condition by laying out how to identify it and the actions to take to manage it. The health model details how to:

  • Detect a manageable condition.
  • Verify that it really is the condition.
  • Diagnose what might be causing the condition as needed.
  • Resolve the condition through corrective actions as needed.
  • Re-verify the condition to see whether the system is in good health.

Tom works with others in the IT organization and relies on existing policies and procedures to formulate an initial health model for the two Web services he has proposed. This initial plan takes into account the company's standard system-level and application-level health models for Web services (for example, the requirement to perform "heartbeat" checking as a way to ensure a Web service is still running). Tom also needs to take into account the requirements in the business operations specifications.

More detailed information on Web service health modeling can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Development and Test Phases

When Tom completes his design, he reviews it with Pam and Zack to make sure they agree it meets their requirements. He then works with Jackie to coordinate the hand-off of the design to the lead developer Sam and his team

One of Sam's tasks is to use the solution design as the basis for developing the detailed specifications of the system. The specifications will take many other factors into account, such as development policies for the IT organization, existing infrastructure, and existing components. Sam must take into account many issues in developing the specifications, including:

  • How to make the application testable.
  • How to make the application deployable and configurable.
  • How to deal with versioning.
  • How to deal with security.
  • How to handle deprecation.

Another of Sam's tasks is to use the health model as the blueprint for instrumenting the solution so it can be managed. Instrumentation is used to provide visibility and control over running instances of Web services. Instrumentation may take the following forms:

  • Debugging traces can help with diagnosing code execution behaviors.
  • Events are used to raise alerts that signify meeting certain management conditions.
  • Performance counters are used to generate statistics that reflect the health of the services.
  • Probes are internal service states that can be queried and controlled by management applications.
  • Based on these specifications, Sam's team programs the software for the solution. Sam works with Jackie to come up with the schedule for code reviews and hand-off dates to Kim in test.

Kim collaborates with her team to design the tests that will verify application compliance with governance. She designs the test harness to subject the application to different kinds of tests, for example, functional, performance, stress, and security penetration testing. The key issues Kim must decide are:

  • Unit testing.
  • Datacenter deployability.
  • Health model conformance.
  • Manageability.

The pre-production test environment simulates real-life conditions to validate the Web services design assumptions. Kim works with Jackie and Sam to schedule the test passes and bug triages.

  • More detailed information on Web service solution design can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Deployment Phase

After the new Web services have satisfied all testing requirements, they are ready for deployment into the production environment. Dan starts by preparing the network infrastructure, hardware, and operating systems. He then deploys the application to the production environment. Key issues that Dan must decide are:

  • Provisioning.
  • Versioning.
  • Discoverability.
  • Windowing of update rollout.
  • Cluster management.
  • Integration with infrastructure change management.
  • More detailed information on Web service deployment can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Operations Phase

After the application is deployed, Jackie's work is mostly done. Craig and his team take over to monitor the application to determine whether there are any operational problems. The goal of this phase is to maintain system health according to the health model. Key issues that Craig must focus on are:

  • Health, performance, and service-compliance monitoring.
  • Root-cause analysis.
  • Metering.
  • Service control and configuration.
  • More detailed information on Web service health modeling can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Change Management Phase

During the change management phase, Craig, Sam, and Tom look at the operations data for the service including real-time and post-processing. This phase involves a decision-making process to decide on design or implementation changes. Key issues the operations staff, developers, and architects must focus on are:

  • Health model metrics.
  • Deprecation.
  • Infrastructure adjustments for scaling.

Over time, new business operations and technical requirements will necessitate re-evaluation and possible changes to existing implementations of the product shipping business collaboration and the IT system that underpins it. As these changes occur, Northern Electronics will be faced with the challenges of minimizing or insulating the change impact to existing participants within the business collaboration, as well as to consumers of the Web services.

For example, if Northern Electronics decide to extend the reach of the product shipping business collaboration to transport consolidator partners who ship overseas (instead of those who only use national trucking), adjustments will need to be made to the formal model of the business collaboration—for example, to take into account international customs regulations. To support these new requirements, additional input or output data may need to be passed between the supplier and the transport consolidator. These changes in business operations requirements can be communicated clearly and effectively to the IT organization by means of revisions to the business operations specifications.

Because Web services are used to enable parts of the business collaboration, a couple of technical options may be considered to facilitate such new data exchanges. Northern Electronics may introduce a new Web service interface to support the new data parameters. Or it might use a Web service proxy façade to support the existing interface, with the proxy performing data transformation and internal service routing to support messaging requests from current and new service consumers. Depending on the Web services solution design, changes to the Web service interface or message schema may affect the Web service consumer and the Web service proxy. In either case, the consuming party would need to discover the new Web service definition to interact with the new Web service endpoint.

The Web services that underpin the product shipping business collaboration could require changes not necessitated by changes in business operations. Such changes could include a slight change in the Web service access addresses, or substantial changes to an existing message schema that proves unuseful or incorrect. The IT organization should be able to make these changes on its own, but it will need to coordinate the changes with the business operations staff for their consideration of the impact and feedback on time frame within which to accomplish the changes.

Conclusion

This document has followed the story of how Northern Electronics worked with its business partners to improve its product shipping process. The discussion showed how business operations requirements can be supported in the IT organization. Other documents in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT rely on the Northern Electronics scenario to examine in more detail from a variety of perspectives how to manage connected systems.

Show:
© 2014 Microsoft