The statement “Design is the evolution of information punctuated by decisions” first appeared in The Journal of Engineering Design in 2001(Ullman 2001). Now, ten years later, Product Lifecycle Management (PLM) has evolved to do a superb job of managing design information and is moving toward robust decision management. This paper explores a decision-centric view of product development and implications for PLM capabilities needed to fully punctuate the entire product life cycle.
The points made in this paper are based almost entirely on the results of research into how people do design and make decisions. Some of the references are for work done by the first author beginning in the 1980s. His focus began with efforts aimed at understanding how engineers design products from a cognitive viewpoint and they matured to developing methods to support team decision making activities. This body of work was intended, from the beginning, to support systems that could manage design information – exactly what PLM does.
System design is the evolution of information punctuated by decisions, decisions that are based on uncertain and evolving estimates from agents, web searches, simulations, tests, experience, or wild guesses; all tempered by conflicting human values, estimates and beliefs. The uncertainty creates risks with every decision made, regardless of whether the decision is focused on the architecture of the system, the relationships of the sub-systems, or the configuration of code, parts and assemblies in the sub-systems.
In this essay, I will discuss four “Kinds” of decisions. Decisions of the 0th Kind are informal, based on intuition or single point analysis. Decisions of the 1st Kind use a structure to help explore the decision-space and then test the results to investigate uncertainty. Those of the 2nd Kind are built on the assumption that uncertainty is a variable that permeates all information, not an after-thought. Finally, Decisions of the 3rd Kind are adaptive, fusing man and machine, understanding the current situation and past decisions in context, and tracking the inherent risks faced in the current situation. All four types will be developed here, but in practice most decisions are made using 0th Kind logic; mature organizations utilize the 1st Kind for major decisions; few use the 2nd, and the 3rd is glimpse into the future.
Whether you are a seasoned manager for a large corporation or an undergraduate student, training as an enterprise architect makes good sense. Getting a TOGAF certification can transform you to a sought-after professional by corporations around the world at a time where only 5% of companies use it and trends show increasing demand for qualified practitioners. Members of this 5% club are companies that are at the forefront of management techniques, and leaders in their markets (like Intel, Volkswagen AG, Intercontinental Hotels Group). Others (competitors or not) are taking notice.
“Eco-system services” is a recent term that describes the benefits humankind gains from its interaction with natural resources. As such, it requires making complex decisions at the intersection of ecology, society and the economy. In this paper we are specifically interested in the process of making eco-system services decisions in a manner that; considers the interaction of all types of information, honors all stakeholder viewpoints and measures the impacts on all three parts of the intersection. These decisions are often spatial, multi-objective, and based on uncertain data and estimates. Eco-system services decisions are generally focused on: provisioning, such as the production of food, energy and water; regulating, such as the control of climate and disease; supporting, such as nutrient cycles and crop pollination; or cultural, such as spiritual and recreational benefits. Eco-system service decisions in these areas are complex and plagued by uncertainty. The choices made during the decision-making process have potentially far reaching and crucial impacts across the many diverse stakeholders. In this paper we outline the characteristics of a system to support ecosystem services decisions and present an example of a system developed for supporting a representative, provisioning problem.
The Observe, Orient, Decide, and Act Loop (OODA) was developed to describe the process needed to win at war. Recently, the OODA Loop has been applied to business and product development as a way to describe decision-making cycles. In these situations, the loop often gets stuck at the D, and the team is reduced to making a sound like OO-OO-OO. This paper explores why it gets stuck and how to put the D in the loop as a basis for effective action.
This MindMap provides an Integrated view of TOGAF ADM "DATA". TOGAF stands for The Open Group Architecture Framework. ADM is the acronym for TOGAF's Architecture Development Method. "DATA" stands for Deliverables, Artifacts, Techniques, and Approaches. It is a unique view that brings all of this information together in one visual.
After completing one of the most successful defense shipbuilding projects in world history in 2007, the Australian naval shipbuilding industry faces a major crisis. On 25 November 2014, the now ex Australian Defense minister David Johnston claimed that Australian shipbuilders "couldn't build a canoe" and the present government still seems determined to send all naval shipbuilding offshore as soon as the current over-time and over-budget Air Warfare Destroyer project to complete three ships is completed. The major success was the $7 BN stringently fixed-price contract for Tenix Defense to engineer, build and complete 10 ANZAC Frigates for Australia and New Zealand including crew training and full logistic support. In this project all ships were delivered on time, on budget, for a healthy company profit and happy customers.
Somewhat justifying the Government's attitude towards Australian shipbuilders is the fact that Tenix Defense failed so badly to complete a much simpler $500 M project to supply and build a transport and 6 patrol vessels for New Zealand that the company was sold at auction to BAE Systems in 2007 at the same time it profitably completed the ANZAC Ships and won the approximately $2 BN project to complete two Spanish designed and assembled Landing Helicopter Dock ships (small aircraft carriers).
Bill Hall, a Principal of EA Principals, who worked for Tenix Defense as a knowledge management analyst and systems designer through the entire 17½ year ANZAC Ship Project, is preparing a case study of that successful project and an analysis of why Tenix and the Government failed to learn any lessons from it. When the ANZAC Ship Project started, there was essentially no naval shipbuilding industry in Australia, yet Tenix managed to recruit the skills it needed, and build the enterprise architecture it needed to perform well on the project.
A key component in that architecture was the implementation of a clear architectural understanding of the authoring and configuration management of knowledge as captured and represented in engineering technical data and documentation through the entire design, production, and operational history of the project. Unfortunately due to their inability or unwillingness to develop the necessary conceptual understanding of the architectural solutions, neither Tenix's senior management nor Defence procurement administrators developed any appreciation for the value of the data and knowledge management solutions developed for the ANZAC Ship Project (and also deployed in Tenix's Land Division), and did not apply them to other projects.
Bill has outlined the findings of his case study in a presentation to the Australian SIRF Knowledge Management Roundtable.
Bill's presentation, Failing to Learn from Australia’s Most Successful Defense Project, can be downloaded below.
One of the best opportunities for Enterprise Architects (EAs) to show value with transformation initiatives is via help on scoping the work. By combining what TOGAF® prescribes for its Phase A (Architecture Vision) with key elements from ArchiMate®'s content metamodel, one can take a reusable approach to help align possible Courses of Action (choices for scope) with the goals and valued outcomes that the stakeholders desire. But along with that, one can also align the EA Capability with the Courses of Action -- or possibly determine what additional resources EA needs to help pursue a Course of Action. In addition, using ArchiMate®'s Implementation and Migration layer, one can, per TOGAF® derive a projected roadmap and schedule for the scoped effort. TOGAF® recommends doing a Business Scenario to help create an Architecture Vision (scope), and EA Principals has created a Mind Map of a way to do this using ArchiMate®, which means it would be easy to create models to help with the analysis and communication. The Mind Map uses only elements from ArchiMate®'s Motivation Aspect/Perspective and its Strategy and Implementation & Migration layers so that scoping can be the priority before diving into work at the core architecture layers. Please see the applicable Business Scenario Template, available for download below.