The Quest for the Lowest Level Process

Share |

My last two blogs focused on implementing the SID.  For a change of pace (and subject), this blog will look at implementing the eTOM.

Was back in China this past week, working hard and sampling some more culinary delights.  One delight that is hard to find in Shenzhen, where I was, but is found pretty easily in Nanjing is egg dumplings.  The wrapper for these delicious morsels is made of egg, rather than the traditional dough wrapper.  They are often served in a broth or hot pot together with Chinese vegetables.  Tasty.  And for those of you looking to try your hand at making these, here is a link…. www.redcook.net/2009/02/08/egg-dumplings/.

Part of the delight of eating dumplings of any kind is finding out what’s inside.  This also applies to decomposing processes, which, besides eating, I was also doing while in China last week.  You don’t know if the process decomposes further until you “look inside it” by decomposing it further.  That’s one good guideline to follow in the quest for the lowest level process – you never know if the lowest level has been reached, unless you keep decomposing until it appears you have gone too far!  You can always roll back the decomposition back to the previous level.

Now, I could start a war by providing a suggested set of properties for a lowest level process, often call an elementary process.  And I have participated in some of these wars in my past lives!  So, what I propose here are some guidelines that indicate decomposition of a process has not YET reach the lowest level.  Which means if a process exhibits any of these properties, its decomposition should continue.

Please know that this is not an exhaustive list either.  Just some I have found useful.  They can be applied for anyone implementing the eTOM and extending it to levels lower than currently contained within this component of Frameworx.

· If Semantic Analysis, which involves analyzing a process’ description looking for verbs/nouns or phrases which imply some action on an entity, association, and/or attribute, can still be applied to the process description.  This means that there are implied sub-processes into which the process can decompose.

· Acts on (creates/updates) multiple states of the same entity, which implies a separate sub-processes for each state

· Acts (creates/deletes and sometimes updates) on multiple ABEs (a group of closely related entities), which implies separate sub-processes for each ABE, particularly for creates/deletes.

· Carried out by multiple individuals, roles, organizations, which implies separate sub-processes, often associated with each individual, role, and/or organization.

· Carried out at multiple locations and/or at different times, which implies separate sub-processes for each location and/or time.  Note that particularly the time separation implies that that once the process begins, its execution cannot be stopped and then continued at another point in time.

These guidelines can be applied in any combination.

If you have any guideline you would like to share with others, it would be great to hear about them.

You may also be interested in the Level 4 work that is being published as part of a guide book (GB942MAP) that describes and explains the use of mappings between Frameworx c omponents.  It includes Level 4 processes that have been developed by the eTOM/SID mapping team in the Fulfillment and Assurance verticals of the eTOM.

This guide book in draft form can be found at… http://www.tmforum.org/DocumentLibrary/GB942MAPSolutionFrameworks/40793/article.html

Work has also been done in the Billing and Revenue Management vertical process grouping.  This work can be found at… http://www.tmforum.org/Community/groups/the_business_process_framework/downloads.aspx?id=artf1937

I’ll be off traveling in the United States the week of 13th June 2010, so look for the next blog when I return.


Posted 06-06-2010 11:50 PM by John Reilly
Filed under:

Comments

Steven Woodward wrote re: The Quest for the Lowest Level Process
on 06-14-2010 5:02 PM

John and all, I hope all is well and you are recovered from your trip.

I totally agree with your directions and stories.   I presented at a software conference on middleware software estimation, approximately 14 years ago and used a story regarding my loving daughter, who once brought an “oreo” cookie snack into my home office when she was 6 years old.  As usual, I hurriedly bit into most of the cookie, only to realize that she (and her mother) had replaced the white sugar frosting with white toothpaste!  For middleware and now cloud services in 2010, it is critical to understand your “filling”, things are not always as they appear!  After my cookie incident (leaving a bad taste in my mouth), I was very cautious and sceptical of kids offering “oreos”.  I would perform analysis to reduce risk and I have successfully avoided a repeat incident, unfortunately software does not have as good memories and often repeats its mistakes and performs inadequate analysis understanding “what’s in the oreo”.

War of the EP

The International Function Point Users Group has been on the “front lines” for many years.  I have been mediating a ceasefire on many fronts and also creating the “interest groups” driven by the industry to be the “UN”.   Since many SLAs and contracts have been, and are, based upon function points ($/ FP), these confrontations can be very volatile.   The “ceasefire agreement” reality is that today’s world is very diverse and dynamic.  The function point framework needs to be used in a flexible and intuitive way to maximize the value and information provided.    Successful organizations and estimation tools distinguish between the different categorizations such as Development, Enhancements, Integration, Testing Only, Middleware, Cloud Services, and Business Functions. From this, realistic cost estimates can be generated using these categorizations. I always stress that function points are no different than meters.  They are a good unit of measure, but must be used in context with other measures and available information to maximize the value from the information collected to enable better decision making.  

The IFPUG community has a meta-model (in UML) to help communicate and complement papers that the New Environments Committee has been publishing in areas of UML, middleware, Third Party and Reuse.  Due to the agility and diversity of today’s world, you need to use this information as frameworks, don’t become “function point rule extremists”.  

The alignment with TM Forum frameworx and IFPUG is incredible; therefore the collaborative opportunities are tremendous.  

Within IFPUG, the general intent for EP identification is to identify all of the unique activities provided in the software for the user.  (simple explanation is, it actually has significant flexibility)

It’s essentially a “flat” model, but the elementary process identification goal is similar.

All of John’s 5 bullets align with IFPUG for Elementary Processes and essentially can be considered as “hints” when identifying EP for functional analysis.

Major additional properties of (International Function Point Users Group) IFPUG – ISO/IEC 14143-1:2007 for consideration:

1) Focus on the goals and objectives for the analysis.  Are decisions being made regarding functionality that is provided in just a cloud service?  Is this for benchmarking externally?  Is this for an estimate to be generated using a parametric estimation tool? Is it to estimate just for the middleware layer up to calling a service?  Is it to model the manual processes?  Is it to model the software functionality contained in an application or package?  (simple case of making sure to continually refer to how the information will be used and leveraged to maximize the value and relevancy for the information collected)

IFPUG Elementary Process Guidelines:

2) Compose and decompose the functional requirements into the smallest unit of activity, which satisfies all of the following:

a. Is meaningful to the user (a user can be a “person” or “thing” such as NE or transducer)

b. Constitutes a complete transaction (not just a step)

c. Is “self contained” (end-to-end, meaningful to the user)

d. Leaves the business application in a consistent state (user can now do something else unrelated)

3) Further, it is considered a unique elementary process if:

a. It has a different set of attributes from other elementary processes

b. It has a different set of ABEs (IFPUG calls them ILFs and EIFs) used as part of this elementary process from  other elementary processes

c. It contains different edit/ validation or mathematical expressions from other elementary processes

4) If the only difference between 2 elementary processes are validation and/or selection “VALUES”, then the Elementary Processes are NOT considered unique  

Quick example:

Add residential post-paid customer

Add residential pre-paid customer

Add business pre-paid customer

Add business post-paid customer

Change residential post-paid customer

View residential pre-paid customer details

View residential post-paid customer details

View business post-paid customer details

View Customer List (includes all customer types)

These are unique EPs (assuming unique attributes and/or ABEs and/ or edits for each, obviously just a subset of elementary processes for example purposes))

Customer report – for Canada

Customer report – for Australia

If it’s just different selection values, then these are not unique EPs.

If perhaps the Canada report has a unique attribute such as HST (unique Canadian Tax), then they are considered separate, unique EPs.  

In the world of today, improved communication, leveraging TM Forum frameworx, with additional complementary guidelines helps generate meaningful discussions that lead to improved decisions.  The IFPUG guidelines are fairly good and provide a solid foundation to facilitate discussion and ultimately make better decisions based upon traceable, intuitive information.  I think TM Forum and IFPUG can mutually benefit, significantly from the work each organization has done or is doing.  

I totally support John’s views that we need frameworks and guidelines, not static “thou shalt” rules that cannot be extended or interpreted appropriately for today’s diverse world.  Successful companies leveraging functional analysis usually have their own guidelines to address their specific “real life” interpretations and extensions to the function point framework.  For consistency, the guidelines need to correlate with appropriate benchmarking and estimation tools being utilized by the company.          

We welcome your feedback! To comment on this blog post please either Log-In or Register to the TM Forum Community

Paid Advertisement
About TM Forum
Introduction, History, Board, Management Team...
Membership
How to Join, Benefits, Member List...
Community
Community Home, Groups & Teams, Blogs...
Conferences
Event Calendar, Management World, Supported Events...
Training & Webcasts
Upcoming Training Courses, Upcoming Webinars, Podcasts, On-Demand Webcasts...
Initiatives
Cable, Enabling Cloud Services, Government and Defense...
Best Practices & Standards
Frameworx, Business Process Framework (eTOM), Information Framework (SID)...
Resources
Document Library, Case Studies, White Papers
Research & Publications
Business Benchmarking, Newsletters, Insights Research...
Copyright © 1988-2012, TeleManagement Forum. All Rights Reserved
Contact Us
Careers with TM Forum
News Room
Privacy Policy
Terms of Use
Sitemap