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?
- 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.
- 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
- The inherit 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.
- The biggest problem with 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 any individual architect is capable 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.
- You cannot gain benefit of
architecture without modeling consistency when you build 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 trade off between 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.
- 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 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 customer involved, and make customer happy is the project goal.