Category: Softwares

Kristen Nygaard, father of object-oriented programming and the Simula programming language, used to say: Programming is learning. Accepting the fact that programming or more precisely software development is a processes of discovery and learning and not a process of engineering and construction are fundamental to bring software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and commented upon by leading software thinkers for more than 30 years. As an example, In 1987 Fredric Brooks JR stated in the “Report of the Defense Science Board Task Force on Military Software” that the document driven, specify-then-build approach lies at the heart of so many software problems.

So where should the software industry go and look for improving their practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs or semiconductors?

Lets take a look at the car industry. When planning a new model, the first thing is to choose a concept or archetype. It‘s primarily an architectural positioning mechanism. BMW X6 is an example of a new concept that combines the properties of a SUV and a Coupe into what BMW calls a Sports Activity Coupe. The thing is that before you can purchase a new X6, BMW has invested thousands of hours and millions of dollars in both its vehicle and manufacturing design. When BMW receives your order, one of their assembly lines will kick in and produce your customized version of the X6.

So what is the lesson learned from this carmaker scenario? The important lesson is that the making of a new car involves two processes: The first process is the creative design process, including establishing the required assembly lines. The second process is the manufacturing of cars in line with customer specification. In many ways these are the processes we find in the software industry as well. The challenge is what we put into the terms.

In the article ?What is software design?? Jack Reeves suggested that the only artifact of software engineering that satisfied the criteria for a design document, as such document is understood and used in classical engineering, is the source code. The manufacturing of the software is automated and taken care of by the compiler, build and test scripts.

By accepting that carving out source code is an act of design, not an act of construction we are in a position to adopt useful management practices that are proven to work. Those are the practices used to manage creative and unpredictable work such as developing a new car, a new medical drug or a new computer game. We talk about the practices of agile product management and lean production such as SCRUM. These practices focus on maximizing return-on-investment in terms of customer value.

For the software industry to capitalize on these practices we must remember: Programming is an act of design, not an act of construction.

Effective software architects understand not only technology but also the business domain of a problem space. Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, and therefore difficult to design an effective architecture to meet the requirements of the business.

It is the role of the software architect to understand the business problem, business goals, and business requirements and translate those requirements into a technical architecture solution capable of meeting those requirements. Knowing the business domain helps an architect decide which patterns to apply, how to plan for future extensibility, and how to prepare for ongoing industry trends. For example, some business domains (e.g., Insurance) lend themselves well to a Service-oriented architecture approach where as other business domains (e.g. Financial Markets) lend themselves more towards a workflow-based architecture approach. Knowing the domain helps you decide which architecture pattern may work best to satisfy the specific needs of the organization.

Knowing the industry trends of a specific domain can also help a software architect in designing an effective architecture. For example, in the insurance domain, there is an increasing trend towards “on-demand” auto insurance, where you only pay for auto insurance when you actually drive your car. This type of insurance is great if you park your car at the airport on Monday morning, fly off to your work destination, and return Friday to drive back home. Understanding such industry trends enable you as a software architect to plan for these trends in the architecture, even if the company you are working with hasn’t planned for them yet as part of their business model.

Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may influence the type of architecture you design. If the answer is yes, the architecture might include many layers of abstraction to facilitate the merging of business components. If the goals of the business include increased market share through a heavy online presence, then high availability is most likely going to be a very important attribute. As a software architect, always understand the goals of the company you are working with, and validate that the architecture can support these goals.

The most successful architects I know are those who have broad hands-on technical knowledge coupled with a strong knowledge of a particular domain. These software architects are able to communicate with C-level executives and business users using the domain language that these folks know and understand. This in turn creates a strong level of confidence that the software architect knows what he or she is doing. Knowing the business domain allows a software architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.