Product Value Management

When enterprise architects are approached by business stakeholders to help improve business process, in most cases they have to come up with some creative use of information management solutions. Today, there are two basic paradigms that they can base their solution design on. One is application software, and the other is SOA. Both require methods and tools to establish a business solution. And these methods are very different.

Increasingly, enterprise architects find themselves very reluctant to resort to using additional application software, since in many cases they have reached saturation point where adding another application makes processes more confusing and less efficient due to overlaps and difficulties of normalizing business semantics. Many companies today have reached the saturation point with applications. To these companies SOA is and should be a very promising concept. It says that one can increase process automation coverage by reusing already established capabilities. It also says that changing and reconfiguring processes can be technically done much faster and with much less cost. It also uses business needs to drive solutions not the other way around. As much as SOA makes sense, it’s lack of wider adoption does not. What is making SOA difficult to practice? According to my recent discussions with nearly a dozen of early adopters, the main culprit is in misalignment of methodologies. Enterprise architects simply resort to the methods they have been familiar with for many years - exactly those that fit well application software paradigm, the one that they are trying to replace. EA-s still follow frameworks well tuned for business process re-engineering and packaged application implementations. They simply do not come across well defined methods for SOA paradigm right now. Yet, few that did well with SOA and are quite happy with early adoption results, report that such methods have been established already in their companies. Except, in other area of business. Where did they find these methods?

Modular system architecture is intuitively familiar concept to product designers and engineers. Just like products, business processes undergo conceptual design, detailed engineering, prototyping, test and validation, first release, ramp-up and full scale roll-out to the end users. It is very critical to reduce cycle times, control budgets and achieve first time quality of products, so is the case with business processes and information management solutions.

Over many years of practice, product design engineers have adopted sophisticated models to represent mathematically (some would say virtually or digitally) complex products that need to satisfy a range of requirements of end users, manufacturers and distributors. Using model-based design and simulation, product architects turn cross-disciplinary knowledge into innovation. By expanding their models to capture more requirements, design and manufacturing rules at increasingly deeper detail, engineers rely less on physical prototypes, are able to clarify requirements early, avoid costly mistakes and explore wider spectrum of alternatives to further enhance product performance, quality and reduce costs. As a result, lengthy change management cycles at later stages of product and process design are eliminated and resources spent on rework can be redirected into increased throughput of new features. Suffice to say, in an increasingly competitive manufacturing arena, model based design and engineering becomes strategic source of sustainable market differentiation.

No other area of product development has this approach as evolved as mechatronics. In mechatronics, we represent entire system of elements using virtual models to evaluate system responses to usage, production and service conditions. That way, design engineers can eliminate some and fine tune other design concepts through series of adjustments until all user requirements are satisfied and designs meet all other business criteria. Furthermore, same models can be used for synthesizing detailed design artifacts such as embedded software code and logical and physical layouts, supporting a complete design process within model based paradigm.

Creative enterprise architects intuitively recognize benefits of model based approach, and use same principles when they have to design and engineer business processes. In their approach, organization is a system comprised of functional elements that interact through interfaces and can be configured to satisfy a range of requirements. Business process is then represented by models that allow validation of various configurations, working conditions and responses to those conditions. Variability of performance metrics to variances of inputs can be analyzed to optimize design of business processes. Thus, resulting set of configurations satisfies full spectrum of requirements of the end customers, is robust to disturbances and is designed to operate within desired metrics. Furthermore, these process models can generate very detailed specifications for implementation of information management systems (functional capabilities, data interfaces, process flow logic, etc).

So, why is it that enterprise architecture largely remains oblivious to these principles? We are still witnessing document based frameworks, proliferating drawings (maps) of process flows, often depicting a severely limited set of configurations, that cannot be used for any analyses or simulations, never to mention self-generation of implementation artifacts. As if business processes do not change often enough to require fast and accurate response. Lack of model based enterprise architecture techniques and methods is a main culprit for slow adoption of SOA, otherwise a very promising paradigm of business automation.

Mechatronics system architects have abandoned drafting boards and have reduced dependency on physical prototypes. They have developed models for simulation and analysis of key requirements. They reuse standard interfaces and common components. They have developed methods for managing user options and configurations. They have parts management systems. They can evaluate critical parameters to make architectural trade-offs… Enterprise architects are still drafting, they are still struggling to make lists of parts and generate part numbering schema for standardization and reuse. They communicate using unstructured documents and slides. They are not sure what performance metrics to use for evaluating alternatives…

I have a recommendation to EA-s who rightfully have reached conclusion that SOA is superior to application chaining, but have been frustrated to date with the lack of sound methods. Spend some time working with product, particularly mechatronics architects, and ask them how would they develop a solution starting with a given set of requirements. Look how they model product functions based on requirements, how they reuse these functions, represent complex configurations, measure and evaluate system responses, and apply components standardization and architectural modularization. Then apply these principles to modeling your organization, organizational functions, standard interfaces, operational metrics, process configurations, rules, roles, … Simply, stop drafting, start modeling and many useful principles of SOA will fall into place. Take a look at reference models delivered by non-for-profit Value Chain Group http://www.value-chain.org. Their VRM and SOA-IM reference models are an excellent catalyst to jump start your model based enterprise architecture approach.

Defining product structure (what is key prerequisite for any PDM system to work) that will satisfy needs of all users is still a “holy grail” of PLM. To make it a more attainable goal, compromises are required. They entail reduction of scope (often targeting a group of users sharing some relatively well defined product view - e.g. manufacturing release of the product), and standardization of the product definition within that scope (e.g. part numbering nomenclature, hierarchical trees, attributes, naming rules, etc.).

Even when limiting scope, to bring everyone to speed on how to use the information management solution may take long time. Stories about out of the box, fast and easy enterprise wide adoption are largely unfounded (most in fact relate to cases where a handful of early users test the system as a proof of concept for larger enterprise adoption). The limitation at play here often is less related to software. The culprit is nature of creative professionals to resent structure when it comes to sharing information. Yet, without sharing information in a fast and efficient manner, product development cannot be planned nor executed with quality and timeliness required in today’s business environment. Let me elaborate on this before coming back to the main dilemma - when to use structured and when to use free-form approach to product information management.

Like many other information management solutions, systems used for product information management serve four main purposes: storing data, retrieving data, finding information, sharing information. For the purposes of storing and retrieving data, databases with relatively simple meta-data structures suffice and that is what most information systems found today in product development are designed for. In order to support finding and sharing of information, systems need to use structures with much more complex data models representing contexts within which the information is used. Visualization and 3D viewers coupled with structure trees are very popular for this. Yet, there is a myriad of contexts in product development not supported with any system. Since most information systems, in order to be successful, are designed with a narrower scope in mind, an inclusive data model that represents all contexts is not present in any single system. Consequently, structures useful in supporting data storage and retrieval for one group of users may confuse another group of users who simply want to see the same data in a context not considered in the system storing the data. For example, a product planner would love to know what would be a true cost of a new feature for which the price is yet to be determined, or sourcing manager may want to know how heavy are die cast parts of specific material (lets’ say zinc alloy) currently being designed across all products…

Structures often get in the way of creative thinkers who over time develop alternative information searching and sharing solutions, following an informal (or free-form) approach. Let’s examine our options here. I see three options, first one being alluded to above - a single data model supporting all contexts and all data required to generate information in all of the supported contexts. To support the fact that data is changing continuously, this option would require not only that all possible contexts are supported by the single data structure, but that all data be stored in a common repository and governed with a central meta-data authority. It is frightening to see how many enterprise architects out there still believe in this utopia. Second option, is to move data back and forth between various authoring databases to support multiple contexts represented in multiple systems. This option is popular when limited to just few systems and contexts, but would become unwieldy when extended to all recognized contexts. Change management would bring this option to its knees.

Here is a very interesting fact: vast majority of enterprise architects consider only these two options, quickly determining that second one for practical reasons will have to deteriorate into first, once the entire domain of structured product information is considered. While these two options are different in the architectural concept, essentially both options require product structure definition up-front.

Third option is to let the product structure evolve using morphing free-form definitions of the contexts within which the information is exchanged. In fact, that is what is going on in most of development organizations. As much as we would like to believe that our information systems bring discipline and order, we also have to be aware of the fact that they only cover a tip of the iceberg of the critical information and based on which decisions are made. As it follows, informal information sharing is a predominant approach to product development information management today. Usually, only final records of decisions make it to some structured data capture format where they are managed through subsequent iterations. Most contexts and problem solving steps that lead to these decisions never get tracked through any official data repositories. Social rules like authority and credibility govern the information sharing in the free-form approach.

So, what would the free-form approach look like. First, it is not based on product definition structure, but on organizational hierarchy and taxonomy of various skills and knowledge items. It lists all people who participate in the process and through series of associations with roles and key words describing their work products, it provides quick look ups of who should be in charge of what work product. Just like in this blog, each participant would maintain a log of tasks and/or posts that link to the underlying data directly related to their work products (3D designs, part tolerances, tests, material costs, …). Here, even some fairly loose governance comes handy. For example, some users could automatically publish their task logs from internal tracking systems providing they have used them for their work. Others could choose from pre-specified log forms that are appropriate for the type of task they perform. Within these forms, links can be inserted to specific digital artifacts (data and documents) contained in their internal authoring systems. In each case, system architects would enable series of policies for retrieving and storing data directly into the systems through free-form entries wherever the logic of the process allows for it. Web services and XML document types come very handy for this purpose. Thus, exposing data from the authoring systems in contexts freely maintained by the users allows for fast finding and sharing of critical information.

Using structured and free-form approaches combined enables best of both worlds. Structure helps maintain and manipulate vast amount of data, while free-form contexts make that data available to all users based on their natural way of sharing it. Over time, the two can evolve, replacing the free-form contexts with mature structures (repeatable patterns) and allowing for new contexts to take shape as they are being discovered by the users. Governance in this approach is much more relax than in either centrally managed repository or system to system data exchange. Semantic reconciliation is simply left to people to execute through their internal preferences and shared points of view, while structured information does not need to cover complex contexts, becoming more and more reusable and reliable. Latest updates from several companies developing free-form solutions for product information management is more and more encouraging pointing to an accelerated adoption in the near future. Insight into early adopters shows very elegant solutions coupled with strong 3D and visualization capabilities, XML content re-purposing and web services for in-context data retrieval. Amazingly, the technology components required are very low cost, mostly available already in many companies, while best practice governance ideas are already forming as very portable and powerful policies for information sharing and search. My recommendation is to try free-form approach using common portal technology in limited scope (such as systems requirements management, simulation data management, test and validation) and observe how the organization reacts to it.