03.06.12
Questioning the Rules
[Cartoon]
Is it necessary to design software before it is built? In most cases the answer to this question would be to apply engineering principles and design would be the first step. Yet, if our software could be assembled from existing components we might spend our time trying out different combinations.
There are many reasons why design should occur first. Design gives a project clarity, direction, and limits the scope. Design shows how all of the components of a project come together to create the final deliverable. This brings clarity. Because components have dependencies, the order of component construction sets the direction for the project. Because the design defines all of the components needed for the project, the scope of the project is limited to those components.
When a project has a design, and therefore project clarity, direction, and limited scope, funding can be requested. During the funding review, the design decisions can be questioned to determine if there might be less expensive approaches or potential reuse from other projects.
The entire project portfolio would be reviewed to determine the best opportunity to start the project. The concern is always the impact of change on the organization and trying to avoid overlapping changes to specific organizational units.
Sometimes a project will not be funded due to the benefits not outweighing the costs. When this occurs, all the effort that went into the design and project review will be lost. It also sets a standard that other project designs will attempt to avoid.
So what if we didn’t design? Assume we had the components necessary to try different combinations. When we strike upon the combination that everyone likes, we are done. The software is built.
The problem with this scenario is the assumption. When it comes to most software construction, we don’t have the components to try multiple combinations. These components would need to be available for every form of business and have the ability to snap together like pieces of a puzzle.
This problem can be solved by applying the rigor of ontology. Ontologies are constructed for specific domains. These domains represent unique business or scientific knowledge. By using an upper-ontology, these domains can be combined in different ways and tried without design.
The upper-ontology would be an Enterprise Architecture ontology that provides the definition for services and processes. In this approach there would be no engineering type of design. Ontology components would be combined by including components and connecting service references with services.
Assembling components to produce software allows for the maximization of creativity within the constraints of the components available. Since assemblies must stay within the constraints of the ontology components, there is built-in proof that the resulting software will produce correct results.
As we move towards construction of software based upon knowledge captured in ontologies, we will see the “design before build” principle vanish. Our focus will be on defining ontologies that best reflect the realities of a specific domain and assembling multiple domains to define software a business. This will occur without the principle of design first.
Enterprise Architects are well-aware of the continuing evolution of technology. They creatively look for technology convergence that can provide breakthroughs in thinking. We are at one of those convergent junctions today. What is about to happen will give non-professional information technologists control of their use of automation in their business. No longer will they simply peer through windows and see only what applications let them see. They will be able to go inside, see how things work, and control their automation. – Enterprise Architects Masters of the Unseen City
Closing the Business / IT gap.
