Three presentations in this morning session on Wednesday, May 18 at SATURN 2011 examined how architecture interacts with other parts of the life cycle; for example, the relationship between architecture and requirements, the business cycle, and testing.
How to Break a Mammoth Project into Bite-Size Pieces
Esther Johnson and Kevin Nguyen, Northrop Grumman
Reasons for software project failure:
- poor communication among stakeholders on project reqs
- poor planning on resources, activities
- poor quality control
- poor estimation
- poor risk identification and management
Systems of systems (SoS) are too complex to play “bring me a rock.” Need to redefine the way we design and build SoS.
Northrop Grumman’s Architecture in Practice. Sustainable model-driven architecture development processes. Framework for customers, management, and architects to work toward common goals. Tangible steps and example artifacts to allow architects to clarify requirements understanding with various stakeholders. Goal is to catch design deficiency early. Common understanding for customers, managers, stakeholders, architects, and developers.
Each phase of architecture development revolves around circle of activities: input from customers and other stakeholders –> process –> create artifacts –> show to management –> make presentation –> input …
Architects are able to absorb input from both customers and managers, leading to customer satisfaction and alignment with corporate product line.
Prototypes and design spirals to increase buy-in of software people in architectural decisions that impacted the project. Software focused on needs of end user and user experience. Architecture has to live throughout the life of the system; can’t be thrown away in software development.
- Rule 1 – construct a good map of your architecture.
- Rule 2 – document architecture in depth.
- Rule 3 – validate design decisions.
- Rule 4 – manage scope of stakeholder reviews.
Womb-to-tomb requirements trace. Integrated tool suite generates specifications and maintains traceability.
Process and tools contribute to consistency in architecture.
Nurturing the Domain, Avoiding the Pig-in-a-Poke
William Martinez Pomares, IASA, University of Costa Rica
Making requirements useful for the end user. Enterprise architecture should not be only architecture. Technology should be used as a strategic asset. Building things for strategic goals.
A pig-in-a-poke, a cat-for-a-hare: You’re expecting something and you get something similar but not quite what you were expecting. For example, an accounting system for a banking system. A database-driven system instead of something else. User should not need to know about databases to use a system. Need to make the operation of the system intuitive to user. Two comparable applications might do the same thing, but a bad one has concepts from a domain with which user may not be familiar.
Forced domain anti-pattern: use of a foreign domain in a solution. Problem: couplings, breaking process, semantics disparities, and solution gap (pieces that are missing in the solution for the user).
- “A new expert is coming, we need to train him on the system.”
- “Get me IT, we need to explain the process.”
- “Honey, I’m late for dinner, we got a new system.”
- “And this nice chart is the hard work of John, who got all the data to put it into Excel.”
Shadow architecture: set of unofficial solutions. Gap between requirement and solution in technology, organization, business, process, and people.
- development – speed, precision, trust; modeling, validation, coherence
- adoption – impedance mismatch, no ownership; workarounds, conflicts, barrier, even Sarbanes-Oxley
- evolution – unnatural patches, no flexibility; no governance
A domain comprises core, process, and communication. There are at least two domains in a business, IT and business.
- awareness (people need to know about domains)
- language standardization
- continuous evaluation
- governance integration
Tips, tricks, and more
- domain-specific languages
- in-depth reviews
- services; expose business knowledge and integration
- language simplification
- technical discussion (talk at communication level)
- semantic dissonance
- bottom-up development
- service as RPC
- wrong domain identification
Organizational Design Thinking
Anthony Lattanze, Carnegie Mellon University
Chasm between architectural design and organizational design thinking–design permeates everything we do. Integral part of organizational processes, marketing, management, and production. Architecture is now a key part of business strategy.
Pain point 1: Drive-by training doesn’t work and rarely results in lasting changes in practice. Hard to map classroom principle into practice. Organizational design thinking involves more than just training. Training has to be part of a comprehensive plan to develop organizational design thinking. Training must include, for example, transition and adoption strategies.
Pain point 2: Once trained, most architects indicate that putting training into practice is a challenge. Have to define a design process. What, how, who’s responsible? Goal is to shorten period of time between when there are many unknowns and when you have a completed design. Design process must be detailed–defined roles, artifacts, inputs/outputs, pre/post conditions, wedded to process frameworks.
Architects must be consulted and must provide serious technical assessment to marketers with ideas and managers who make resource allocations. Failure to involve architects leads to unrealistic expectations, missed price points, missed value propositions, business misalignment. Marketing people imagine products that defy chemistry, physics, and mathematics. The technical view must be present at product-definition time.
- comprehensive training plans for organizational design thinking including exercises & critique, training, transition
- Define an architecture design process
- Teach architects about organization, business, and marketing thinking
Create processes that enable managers, marketers, and architects to work together early in the product life cycle.