I spent the last two weeks on vacation, cruising down the Danube river with my wife Jeannie. It seemed like, as with a lot of vacations, we fell into a pattern during our visits to a number of cities. Seeing the town center, palaces and castles, and eating. And there were some things that didn’t fit the pattern, such as when we decided to have a good ol’ American hamburger in Budapest.
We all live with patterns and non-patterns. The components of TM Forum Frameworx contain both. Patterns are good, because, among other benefits, they represent a consistent approach to modeling. Patterns are used to develop all the components of Frameworx, such as developing the Information Framework (SID), decomposing processes in the Business Process Framework (eTOM), specifying and developing TM Forum interfaces, and identifying and defining Application Framework applications. But, there are always situations that don’t fit a pattern, which is also good, or we would be bored to death! I call these non-patterns.
Patterns aren’t new or unique to Frameworx. Many, if not all, of the patterns that we use have been around quite a long time and even pre-date my old bones. Often members ask me why we picked the patterns that are used. I won’t get into going through all of them but will provide a few examples.
From a SID perspective, the real world provided us with some guidance. When we go shopping on the web, there is often a link to the specification that describes the object of interest to us. This is one part of the EntitySpecification/Entity pattern – the EntitySpecification. And, when purchased, we receive our own personal instance – the Entity. Often the object of interest is a bundle. There is another pattern that can be used to model this requirement, the Composite/Atomic pattern. The bundle is the composite, which may be made up of other composites or bundles and/or atomics, the lowest level objects of interest This also demonstrates that patterns can often be used together to satisfy a set of business requirements.
From an eTOM perspective, the category of object, or entity, often can be used to identify processes. Forms of interactions, such as orders, problems, and such, move through a common life cycle. They are opened or issued, reported upon, tracked and managed, and closed. A more generalized life cycle for any object can be thought of as plan, acquire, use, dispose. This is not to say that this is the complete life cycle. For example, problems must be isolated, which doesn’t make sense for an order! So patterns can be viewed as a starting point for modeling.
Which leads to also thinking about non-patterns where a requirement cannot be satisfied by a particular pattern. I’ll provide just one example from the SID to make this point. Currently the group of entities, called an Aggregate Business Entity (ABE), used to model a Customer, such as Customer, Customer Account, Customer Credit Profile, Customer Contact, does not employ any patterns. Why – because the patterns that are used to model the SID do not satisfy any customer information requirements.
And, certainly, other patterns can be used by members when extending any Frameworx components. I just would try to limit the number used or the resulting model will be much harder to understand. Another point is that to satisfy a set of requirements, a combination of pattern(s) and non-patterns may be employed.
Off to Team Action Week Baltimore next week, and I’m certain another blog topic will be based on the week. Talk to you again soon!
Posted
07-15-2011 9:13 PM
by
John Reilly