Scott Ambler

Scott W. Ambler (born 1966) is a Canadian software engineer, consultant and author, currently Senior Consulting Partner at Scott Ambler + Associates. He is a well-known author of numerous books focused on the Disciplined Agile Delivery process decision framework, the Unified process, Agile software development, the Unified Modeling Language, and CMM-based development.

Quotes

• The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds.
  • James McGovern, Scott W. Ambler and M. E Stevens (2004) A Practical Guide to Enterprise Architecture. p. 35

Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (2002)

Scott Ambler (2002) Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process.

• Ever wish you could draw a few diagrams, press a button, and have a working software system that meets your needs? Sound like magic? Perhaps, but that’s a major part of the Executable UML vision. The basic idea is that you will use a CASE tool to develop detailed UML diagrams and then supplement them by specifications written in a formal language, presumably the OMG’s Object Constraint Language (OCL). The basic idea behind Executable UML is that systems can be modeled at a higher level of abstraction than source code, simulated to support validation of your efforts, and then translated into efficient code. This higher-level of abstraction should help to avoid premature design, enable you to change your system as your requirements evolve, and to delay implementation decisions until the last minute.
  • p. 172

• In my opinion this sounds great in theory, but unfortunately there are several problems to making this work in practice:
  • The UML isn’t sufficient. The UML is clearly not sufficient for business application development, as I argue above, so trying to generate a system only from UML models at the present moment simply won’t suffice.
  • Integrating a collection of tools to support Executable UML is currently difficult. Let’s assume that one or more tool vendors decide to implement the Executable UML vision and fill in the gaping holes inherent in the UML... Because there isn’t a complete standard in place the various vendors will to add their own unique extensions making multi-vendor tool integration difficult.
  • A single vendor approach will likely prove too narrow. Another approach would be for a tool vendor to support both modeling and code generation features in their tool, something perfectly reasonable in theory. But, because of the wide range of platforms, and range of design options within those platforms, the tool vendors will need to focus on a single niche...

  I have no doubt that we will begin to see some interesting tools emerge over the next few years based on the Executable UML vision.

  • p. 172-173