What is Wrong with Current Software Architecture Methods?

 Following the golden rule to get the customer involved, and make the customer happy is the project goal.

Among the reasons why architecture is important, worth studying, and worth practicing is that the analysis of architecture enables early prediction of a system’s qualities. This is an extraordinarily powerful reason! However, it has been said that current software architecture is weak in expressing and evaluating ideas of quantified qualities and costs. It has a lack of rigors, which needs to be improved by moving in the direction of engineering methods. So what are more specific issues in software architecture methods today?

1. The lack of domain-wide business modeling and enterprise architecture planning,  that should have occurred at a higher level and before the project team takes on gathering requirements and designing software solution has an effect on software architecture, quality, costs, etc. The project's end product does a lot but doesn't contribute enough to the expected business outcome so the customers think there must be something wrong with the software architecture process. They are spending too much and yet not truly getting what they need. 

2. The art of the trouble is that software architecture is not a solution in/of itself, but rather a component of the overall business objective. That aspect is often confused as too many architectures are constructed without regard as to why it is there to begin with. They become pet projects and the byproducts of empires. Coupled with the all too frequent deficiency in requirements quality - often devolving into little more than a long list of point functionalities, with little regard to the larger business picture, and most importantly - the fact that these systems must operate for and be understood by human beings 

3. The inherent problem in software architecture is that it tries to solve too much. Software is just one of many factors in addressing a solution and often a solution is not delivered because something fails. Requirement, qualities and cost factor should be prioritizing while comfort zone and market trends taking place when architecting software. 

4. The biggest problem with the software architecture methodologies as a whole is that they lack flexibility. The same set of practices that works in one context will be too heavy in another and insufficient in yet another. In addition, software systems are massively complex and they need to be flexible to continuously change with the needs of the business. Perhaps no individual architect is capable of defining all of the current needs, foreseeing all of the future needs and recognizing all of the potential opportunities for integration or consolidation when defining requirements. Software architects have to revisit the value that the architecture adds to the organization and not make it after the fact as document costs too much with no business value.  

5. You cannot gain the benefit of architecture without modeling consistency when you build a model, and you cannot achieve consistency without using the patterns and tactics. How many of you see these characteristics among the architectures that you have built or worked with? How many of you use architectural patterns and tactics to the trade-off between the qualities of systems? You can analyze architecture to see how the system or systems being built from it will perform with respect to their quality attribute goals, even before a single line of code has been written. But sometimes, the architects design a system instead of architecting it.  

6. More Pitfalls: Software Architecture as sub-component of Enterprise Architecture, all the Enterprise Architecture pitfalls may also cause that piece fall, such as
   -Improper analysis/knowledge of existing components in the system and lack of understanding on their interfaces to extend and re-use.
   -Not Balance well on EA/SA aspiration & EA/SA Practicality
   -Lack of an effective set of metrics to measure delivery.
   -Time to value or no value delivered or out of date value
   -Do EA/SA for its own sake
   -Culture inertia "that's the way we've always done it".
   -Too much focus on EA/SA tools and frameworks
   - The wrong scope focus from the start
   - Lack of SW Developer understanding of how to use architecture
   - A weak architect: An architect needs the capability and authority to synergize with the functional experts involved in the development and to make decisions and continuously adjust and enhance the system design throughout the development process.  

All happy projects are alike. All unhappy projects are unhappy in their own unique way. Either software architecture or software development project, follow the golden rule to get the customer involved, and make the customer happy is the project goal.

Posted in: EA,Lessons from Failures,Project Management