Why is it that so many people feel it is acceptable to take words and redefine them for convenience? Over on Herding Cats, Glen laments the borrowing and redefinition of words by the agile crowd (a crowd of which I part of until a few years back). I am experiencing one such redefinition: Enterprise Architecture.
I'll start with my quick and dirty definition of system architecture: the function and form of a system and how they relate through the system concept.
To me and some others, enterprise architecture is the structure of an system where the scope is the enterprise (e.g., for profit corporation). The enterprise architecture also describes the enterprise's relationship to outside entities such as capital markets, labor, suppliers, and customers. Further, it describes how the enterprise system will operate and evolve over time.
To others I know, Enterprise Architecture is defined as the information technology architecture at the scope of the enterprise; this is another example of IT co-opting a well defined term. I personally prefer CISR's notion of how enterprise architecture and IT relate: "A firm’s architecture describes a shared vision of how a firm will operate—thus providing a shared understanding of the role of IT." In this way IT is a sub-system of the enterprise system.
Thursday, March 17, 2011
Monday, March 14, 2011
Uncertainty Framework
Over the weekend I came across a paper by McManus and Hastings, "A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems". The authors present a taxonomy covering uncertainty, risks & opportunities, mitigations & exploitations, and outcomes. Then the authors cover the existing methods for dealing with uncertainty and which parts of the taxonomy are used in each method.
This is a pretty short paper and well worth the read if you are interested in all in dealing with uncertainty.
This is a pretty short paper and well worth the read if you are interested in all in dealing with uncertainty.
Tuesday, February 22, 2011
White board drawing of the day
This was seen in my office. If you want projects and products and people to be successful, this might be some of the most important advice:
Thursday, February 17, 2011
Deactivating Twitter Account
Today I deactivated my Twitter account. I think Twitter is a great service for some, but for me if became more of a time suck, delving through pages and pages of 140 character exchanges with nothing really significant being said. This is not meant as a negative toward the people I follow, I would much rather read your blog or see you at a conference where we can interact in a more meaningful, unconstrained way.
Now is the time for me to unplug.
Now is the time for me to unplug.
Wednesday, February 16, 2011
Quote of the day
You don't get what you want want by trying to eliminate what you don't want.
-- Russ Ackoff
Thursday, December 30, 2010
Work Transformation Method Application
As mentioned in a previous post, one of the projects I have completed as part of the MIT SDM program has been to look at the process of diesel engine aftertreatment system calibration. The project team for this assignment was Genevieve Flanagan (lead), Candice Engler, and I. Also supporting us was Oliver de Weck and Arun Balasubramaniam.
After-treatment systems are those components on diesel engines that remove particulate matter (soot) and nitrous oxides (NOx) from the exhaust. Since the introduction of the U.S. Clean Air act, there have been several levels of decreasing particulates and NOx levels mandated; these are sometimes referred to by tiers (Tier I, Tier II, Tier III, Interim Tier IV, Final Tier IV). Because these are regulatory mandates, a producer of engines must either achieve the mandate or not ship engines. Producers of engines also do not want to compromise performance of the engines to meet regulatory requirements. From a project perspective, this is a project that has fixed scope and schedule.
As producers of these cleaner engines have moved up the tiers they have come to rely more and more on software to control the after-treatment systems in order to meet the regulatory requirements. Part of the process of preparing these engines is to calibrate them and their software in a test environment. Calibration activities are resource intensive, both in terms of human labor and capital for the test cells.
When talking with the after-treatment team the calibration activity was largely treated as one large task, with lots of iteration within the task. The variability in the effort and duration for the calibration of each engine configuration was considered unacceptable by stakeholders. We also learned that the after-treatment team had built a design structure matrix showing the calibration and other dependencies between the components (physical and software) of the after-treatment system. The DSM was highly coupled, with few small independent components and one large meta-component.
We investigated various mechanism to better plan the calibration activities, including a signal flow graph approach and visibility matrices. We settled on using a work transformation approach to create the engineering iteration model. We used the DSM to determine a series of 24 design steps (things that were later labeled "sensor calibration" and "determine soot model", as examples) required for engine calibration. These calibration steps still happen iteratively (e.g., an activity done during step 2 may require rework in step 1), but now there are identified calibration modes (as opposed to one large task before). The next step will be to build a probabilistic schedule (most likely using the signal flow graph approach) for the whole calibration activity based on the twenty-four calibration modes.
Another interesting outcome of this project was that a DSM that represented the system architecture of the system was able to be reused, after mathematical transformation, as a project planning tool. This means that changes to the system architecture can be used to update the project plan with mathematical linkages to the underlying architectural change, including determining project impact of proposed changes.
After-treatment systems are those components on diesel engines that remove particulate matter (soot) and nitrous oxides (NOx) from the exhaust. Since the introduction of the U.S. Clean Air act, there have been several levels of decreasing particulates and NOx levels mandated; these are sometimes referred to by tiers (Tier I, Tier II, Tier III, Interim Tier IV, Final Tier IV). Because these are regulatory mandates, a producer of engines must either achieve the mandate or not ship engines. Producers of engines also do not want to compromise performance of the engines to meet regulatory requirements. From a project perspective, this is a project that has fixed scope and schedule.
As producers of these cleaner engines have moved up the tiers they have come to rely more and more on software to control the after-treatment systems in order to meet the regulatory requirements. Part of the process of preparing these engines is to calibrate them and their software in a test environment. Calibration activities are resource intensive, both in terms of human labor and capital for the test cells.
When talking with the after-treatment team the calibration activity was largely treated as one large task, with lots of iteration within the task. The variability in the effort and duration for the calibration of each engine configuration was considered unacceptable by stakeholders. We also learned that the after-treatment team had built a design structure matrix showing the calibration and other dependencies between the components (physical and software) of the after-treatment system. The DSM was highly coupled, with few small independent components and one large meta-component.
We investigated various mechanism to better plan the calibration activities, including a signal flow graph approach and visibility matrices. We settled on using a work transformation approach to create the engineering iteration model. We used the DSM to determine a series of 24 design steps (things that were later labeled "sensor calibration" and "determine soot model", as examples) required for engine calibration. These calibration steps still happen iteratively (e.g., an activity done during step 2 may require rework in step 1), but now there are identified calibration modes (as opposed to one large task before). The next step will be to build a probabilistic schedule (most likely using the signal flow graph approach) for the whole calibration activity based on the twenty-four calibration modes.
Another interesting outcome of this project was that a DSM that represented the system architecture of the system was able to be reused, after mathematical transformation, as a project planning tool. This means that changes to the system architecture can be used to update the project plan with mathematical linkages to the underlying architectural change, including determining project impact of proposed changes.
Tuesday, December 21, 2010
MIT Systems Design & Management
This year I wrapped up my first of two years in MIT's Systems Design and Management (SDM) program on my way to a masters of science degree. SDM is a joint degree from MIT's Engineering Systems Division and Sloan School of Management; I describe the program as an engineering management degree. For me, SDM is a 24 month program. I have been completing the degree remotely while I retain my full-time employment status.
Normally SDMer's start their program with a boot camp in January. Because of unusual circumstances, I have my boot camp experience at the beginning of the second year of the program. For January I will be spending full time on campus completing a few courses and participating in various design challenges, professional development sessions, and cohort building exercises. The required courses include a review of statistics and probability and a course on the human side of technology; if I can fit it in I plan to take another course on technical writing.
The last year of the program has been a very positive experience, even with the required juggling of work, family, and school. The classes have been everything one would expect from MIT. So far my courses have included product design & development, real-options in engineering systems, systems engineering, systems architecture, concepts of supply chains, systems project management, and engineering analysis and design. The projects completed during the classes have been challenging and (I think) beneficial to a better understanding of various systems. I'll plan to write a few follow-up blog posts on the projects:
Over the next year I have many more Sloan (aka management) courses to complete, a few ESD courses, and a thesis to write (of which I am still trying to settle on a topic). I'll work to keep everyone updated as the next weeks and months unfold.
Cheers, Hank
Normally SDMer's start their program with a boot camp in January. Because of unusual circumstances, I have my boot camp experience at the beginning of the second year of the program. For January I will be spending full time on campus completing a few courses and participating in various design challenges, professional development sessions, and cohort building exercises. The required courses include a review of statistics and probability and a course on the human side of technology; if I can fit it in I plan to take another course on technical writing.
The last year of the program has been a very positive experience, even with the required juggling of work, family, and school. The classes have been everything one would expect from MIT. So far my courses have included product design & development, real-options in engineering systems, systems engineering, systems architecture, concepts of supply chains, systems project management, and engineering analysis and design. The projects completed during the classes have been challenging and (I think) beneficial to a better understanding of various systems. I'll plan to write a few follow-up blog posts on the projects:
- Use of Real-Options to Value Vehicle Telemetry Designs
- Multi-attribute Utility Applied to Integration of Bio-alcohols into Existing Distribution Infrastructure
- Use of Design Structure Matrix and Work Transformation to Plan Diesel After-Treatment Calibration Projects
Over the next year I have many more Sloan (aka management) courses to complete, a few ESD courses, and a thesis to write (of which I am still trying to settle on a topic). I'll work to keep everyone updated as the next weeks and months unfold.
Cheers, Hank
Subscribe to:
Posts (Atom)