English | EN Has the design phase become extinct in an SDLC?
Jan 27, 2015
I started my career 21 years ago with Object Oriented Programming (OOP), which was the new buzzword then. I happened to be one of the two fortunate candidates from a batch of 30 freshers to get an opportunity to work in OOP. Back then, one of the very first things I got introduced to was Object Orient Analysis & Design (OOAD), specifically Unified Modeling Language (UML). In fact, after Requirements Gathering, Analysis and Design phases were considered to be the most critical and key elements… before the artifacts such as class diagrams, sequence diagrams, etc. were handed over to the programmers for coding. There used to be strict guidelines about how the design team should identify the domain model/classes, data models and the various manager classes and operations provided by the classes. It was critical because one had to ensure maximum reuse, and maintain an optimal level of code quality to facilitate smooth execution of change management and maintenance phases.
In the last four years, whenever I have been asked to help review projects or improve Non-Functional Requirements
(NFRs) in projects on performance and scalability, I have been shocked (initially) to find that hardly any project creates design artifacts, let alone doing it religiously to create traceability – from requirements > analysis > design > code deliverables. About 10 years back, analysis/design tools such as Rational Rose, TogetherJ, Telelogic Raphsody, etc., along with requirements management tools such as RequisitePro and DOORS, were very popular. Now, vendors like IBM have taken these products to a completely new level, with platforms like JAZZ. So, today, it is possible to create complete end-to-end traceability along with an integrated development and deployment environment including mechanisms of continuous integration. Within my engagements at Capgemini/Sogeti in India, I hardly found any project using tools to create some basic design artifacts. MS Word seemed to be the preferred choice for any design collateral and hence, it turned out to be a one-time document instead of a living document (continuously changing), as it’s supposed to be.
This got me thinking … has the design phase become obsolete?
When I started analyzing the causes in details, I looked at the probable factors responsible for the way software ecosystem had changed over the years:
1) Custom development projects are no longer executed grounds up from the scratch, using languages such as Java or Microsoft. There are mature frameworks such as Spring and Hibernate, which are used to further develop the applications. In fact, nowadays, multiple technologies in addition to Java and Microsoft(.net, C#) are being used in combination.
2) The overall solution landscape has evolved with end-state architectures, having patterns such as service-oriented architecture and integration bus, introducing a separation of concern across these components. Other technology domains like Content Management, Master Data Management, CRM and Big Data and Analytics have also evolved. There are specialized products from various vendors for each of these components. So, each solution tend to be an integration of various components.
3) The number of skills required to execute these projects has increased, thus making it difficult to follow a uniform design template across projects.
4) UML being more Object Oriented does not necessarily support well some of the new technologies.
5) Businesses are demanding quick time to market and hence, a quick turnover of new solutions. This puts pressure on project teams to conduct an elaborate design exercise.
Apart from these factors, Agile development methodology adoption has also grown, but again, going Agile has never proposed reduction of design efforts. Therefore, I am not considering this as a key factor.
In my opinion, to capture design, it’s essential to come out with new languages in addition to UML. Architecture modeling languages like Archimate from Open Group looks promising for architecture, but falls short when it comes to detail designing.
Would like to know whether my architect/designer/developer colleagues share similar thoughts about the way design is being done at present…
About the author
