Friday, July 09, 2004
What Do You Want From Me!?
In my recent digressions on architecture, I have pointed out that the increasing effectiveness of COTS products in the resolution of architectural concerns should lead to a different approach to all specification and implementation disciplines. The question remains: "how do we go about this?" I have learned during my many lives that arguing with kings is not a wise strategy. Therefore, I will "Start at the beginning and when [I] come to the end, stop."
The beginning, it seems to me, is requirements. If we are to implement ADM, we must understand the requirements of our system as it relates to architecture. We must also understand the relationship of those requirements to others, in order to prioritize and establish assessment and mitigation strategies.
Architects have attempted to specify these requirements (often termed supplemental requirements) around reliability, security, performance, etc. In other words, we have attempted to specify the system requirements, as opposed to the business functional requirements, that must be fulfilled in order to achieve all business goals. Collectively, these requirements have driven most (but not all) of the architectural elements of the system.
All of this is well and good in isolation, yet questions arise concerning the integration of these requirements into the more useful business functional requirements of the system. These requirements are also divided into areas. These areas often correspond with business organizations such as accounting, sales, management, etc. These might be further decomposed as necessary in order to determine the best resource for elaboration.
So many ways of looking at the system, and so many experts required to elaborate them. How can we ever hope to bring them together (in any complex system) in a way that fulfills all those stakeholder needs? Remember, we have only covered requirements-- there are still a huge number of processes that must occur, each with their own stakeholder needs, before a final system is delivered.
The answer, in a nutshell, is MDSOC. By allowing the specification of each of these areas (and their constituent decompositions) as concerns, MDSOC provides a mechanism whereby the unification of the concerns can be achieved across all specification and implementation disciplines.
At this time, MDSOC is fairly immature. This is no panacea, awaiting application in order to resolve all our woes. Rather, it is a framework that I believe can be expanded upon to discover the proper processes necessary to evolve software engineering practice to the point necessary to meet the next generation's expectations.
The journey is begun. Proceeding to the end seems a deliciously enticing process, indeed.
