CEO vs. CIO View on Business Activity

Posted by cfaurer on February 2nd, 2012 filed in NGOSS in Practice

There’s a bad misconception running around the executive hallways that the TMF Frameworx (NGOSS) Business Process Framework (eTOM) recommends creating redundant activities specialized for each business area. Wrongo! Quite the opposite actually.

The truth is that the Process Framework (eTOM) is built from a working set of business process patterns that apply the principles of reuse and repeatability across the Frameworx (NGOSS) Domains; Market/Sales, Product, Customer, Service, Resource and Supplier/Partner. The patterns are applied to activities for: planning, infrastructure development, product development and operations (fulfillment, assurance – trouble, performance & billing).

Interestingly enough, what is viewed by many as the latest Silver Bullet for Application Integration, SOA, is actually best characterized as an “executive decision that requires commitment to discovering, mapping and executing repeatable processes”.  [Richard Mark Soley, Ph.D., OMG Chairman and CEO]

Sounds like the Business Process Framework (eTOM) and SOA complement each either other well. And they do, SOA provides the principles for architecting the business processes. And eTOM provides a ready source of industry knowledge about the typical activities required to run a communications company. And the eTOM activities are pattern-based and so already have a natural inclination to be designed for implementation with reuse in mind.

Two key stakeholder groups in any organization are represented by the CEO and the CIO. The CEO typically has responsibility for ensuring that business activities are executing effectively across the organization. The CIO in complement, typically has responsibility for ensuring that the business activities are supported effectively by the operational applications. These two views complement one another, with the CIO looking at processes that run end-to-end vertically whereas the CIO looks at processes that span horizontally (in order to support the information affinity that organizes IT by Domain). Take a look at this slide to get the visual.

By example, the pattern of activities that should have been followed to handle the trouble that I had with my Blackberry would have used the Operations trouble handling flow pattern. My initial inquiry ‘started’ with the Product that I purchased and then should have worked through each dependent Domain until the full Specification tree had been navigated. As each Domain was traversed the Operations flow pattern would have been initiated. Take a look at this slide to get a visual of the Operations trouble handling flow pattern applied to Customer Trouble (Problem) Handling.

Now take a look at the Business Process Framework (eTOM) Service Problem Management activities and see if you can make reuse of the Operations trouble handling flow pattern. Guess what? You can do the same for the Resource Trouble Management and Supplier/Partner Problem Reporting & Management activities.

Add the Information Framework (SID) Business Entity model into the mix to get a view on the information required to support the business processes (can you identify the trouble handling entities in each domain?). And then identify the Application Framework (TAM) application[s] that will provide access to the Business Entities (identify the trouble handing application capabilities).  And to make it all go together, the Silver Bullet application integration bit, the service contract. The Frameworx (NGOSS) TIP (MTOSI & OSS/J) has and continues to work on defining interface specifications that will support such service contracts (did you find the trouble handing APIs?).

SOA and frameworx (NGOSS) taken together provide a useable reference architecture and framwork for achieving that committed executive decision to discover, map and execute repeatable processes.

Leave a Comment

You must be logged in to post a comment.