A Trace in the Sand
by Ruth Malan
3/1/06 Interplay between Requirements and Architecture
I commented in a recent entry that understanding requirements is an act of interpretation, an act which is best led by the architect (or architects). "Requirements" come from various sources. The end-user (in all the various forms this takes) is one, an important source to be sure, but there are others. The business sponsoring the software development has its own stake and its own agenda—the business wants to deliver differentiating value, which has something to do with what users want, something to do with what others are offering, and something to do with its own capabilities and identity. Even the developers who create the software have their agenda. Each of these has only a partial understanding of what they want this piece of software to do for them.
Now, given this situation, there are those in the software field who suggest that we can only approach software along an evolutionary path, where our understanding of what we need to build is actively reshaped as we go, and hence so is the product of our labor. We think that we are so different from other disciplines, that we have a vastly different problem. It is true that if we went about building a house by putting up a bathroom (starting with universal basics) and then deciding what we should add on next, we would laugh at ourselves. We would say, heck, we could model out this problem, get a good grasp of how to tackle the important functions and properties of the building, and then we could set about identifying other concerns and iterate through our models until we had a design that did a good job of the things the stakeholders cared most about and well-enough at the rest, and we'd set about building it. During the life of the building, its inhabitants may change things, but if we did a good job at the fundamentals, the building wouldn't fall down in the process of remodeling.
Ok, so what if we say, yeah, it is much easier to model a house because it is physical. Then you could say a house is but a pile of wood and bricks, nails and such, but it doesn't make sense to (only) see a house that way, if you want to build one. And it doesn't make sense to see a software system as a bunch of bits, or even lines of code. We need to see the bigger structures. The rooms, the flow among them, the supporting walls, the sheltering roof. The components, the interactions, the mechanisms, the subsystems. If we envisage and model larger grained entities, we set ourselves up to be able to create larger grained entities. If we think in terms of objects or even lines of code, we will have to build our systems piecemeal because we are bound to build something to see what we get, and then bound to reshape what we got to better fit the need and the context.
But we don't have to get arms deep in code to understand much of what we are up against, assuming we have done something like this before. We can work with models, and grow our understanding of both the needs and the solution to them through models, figuring out as we do so where our uncertainties are, diving into focused implementation cycles to test out approaches and resolve risk.
Even in novel domains it makes sense to do more of this exploration through models than many of us are comfortable with. Which is why the architect is so important. The architect creates models. Through models we grow our understanding of the interplay among all the forces that are shaping the problem: what the user is trying to accomplish as they go about their overt and hidden agendas, what the business is trying to accomplish, with all of its overt and hidden agendas, not to mention all the tough technical challenges we face in our various domains, from constrained resources, to real-time to security or safety to sheer transaction volume, and so. And yes, there is nothing so good as a working system to make everyone acutely aware of avenues for improvement. But models, mock-ups, prototypes, all help us get a more concrete feel for the tradeoffs that we must make as we balance the needs of various stakeholders against what is reasonable and achievable within the constraints set by these stakeholders, the environment, and our technological prowess.
Which is not to say I am against evolutionary development (in all its flavors from Gilb's Evo and Evo-Fusion, to Agile and eXtreme Programming); indeed I am a strong proponent. However, for most systems it makes a whole lot of sense to start with architecture, and use that to inform our approach to building the system or set of systems. And recognizing that we are always aggressive in what we try to accomplish, hence always stretching beyond what we have done before, we will learn as we go, and we will have to revisit our architecture. My response to that is simply to remind everyone that the role of the architect is ongoing; it is not just an upfront activity that is then left to petrify, in every sense of the word.
3/6/06 Requirements and Use Cases
I had an interesting interaction with William Bufford on use cases and requirements enumeration. William was kind enough to point out Karl Wiegers work in which he describes extracting requirements from use cases.
It is certainly interesting that our papers and pages on uses cases and non-functional requirements get more hits than any other individual pages or papers on our Resources for Architects site. I guess this points to the widespread interest in use cases, as well as the usefulness of these papers/pages. When I asked Derek Coleman to review my use cases paper which quotes his use case template, his reaction was "What's the point, there's nothing new here?" This is an academic perspective, not a practitioners perspective. My counter was that I was simply trying to provide a lucid and succinct overview of what architects need to know about requirements. Apparently this need was felt by a broader community.
3/26/06 Updates to Resources for Architects: Big Ball of Mud
I recently came across Foote and Yoder's "Bill Ball of Mud" site. They write in a racy style, and have a nice use of visual metaphor. I can't believe it took me this long to come across them, and I hold you accountable for not telling me! ☺ Mainly the site is about the state of the mess we're in, and as statements about the state of the mess go, this one is unsurpassed! If you want to motivate your organization to do something about where you are headed unless you get good at architecture, point them to this site! The authors also take a playful look at the general approaches to recovering from the "big ball of mud" state. The vivid and provocative images, metaphors and descriptions convey the sinister truths that plague our field, and some of the architectural approaches to dealing with them.
3/31/06 Updates to Resources for Architects: Product Platforms and Software Product Lines
A client asked for recommended reading in the product platform space, which in the software field has been most intensely investigated under the name "Software Product Lines," led by the Software Engineering Institute (SEI). This also overlaps with work Microsoft has been doing in what they call Software Factories (and what we called "Flexible Software Factories" when I joined Martin Griss' Software Reuse team at Hewlett-Packard Laboratories in 1993). Anyway, I decided to leverage my response into a new area on the Resources for Architects web site and a new links page was born.
3/31/06 Service-Oriented Architecture (SOA)
I realize I need to add an area devoted to SOA to the Resources for Architects web site too. Of course, SOA is going after the perennial problem of leverage. The unit of leverage has been shifting: objects, components, now services. The scope has increased, and the hype along with it. Services, implemented as web services, goes after the integration in heterogeneous environments problem. But SOA, at least the name, places attention where attention needs to be placed to actually gain leverage—Architecture. We face the same problem whether we aim to deliver a product platform and supporting framework of components and infrastructure, or a portfolio of services that will be reused by our various business units to quickly and adeptly create business solutions—Architecture has to be where we begin, and it has to be what we become disciplined about sustaining.
"But if I were a CIO right now, I would have my best people saying: 'We need to get up to the front of this. We don't want to be behind it.' You can do that. What that's going to create demand for is architects, because before you encode the SOA you have to determine how to parse your processes. How do you parse your systems and your modules so that you have a reasonable taxonomy of objects that isn't too granular and isn't too aggregated? That's an architectural discipline, a kind of a systems analysis discipline, but it's got to have a view toward competitive advantage.
And so if you were given that assignment, you'd like the management of the company to say: 'This is what we're going to try to do for core going forward. In the next 10 years, we're going to be product leadership people.' Or, 'We're going to go down this customer intimacy path' or 'We're going to be the operational excellence leaders.'"
Interview conducted on 18 April 2005 by David Smith and Gene Phifer
(Here "core" refers to those capabilities that differentiate the business.)
Grady Booch is also reflecting on the importance of Architecture in SOA, and reacting to the danger of falling prey to the allure of SOA without paying the price of due diligence to architecture. He writes:
"Going back to the A part of SOA, the issue then is one of abstraction, separation of concerns, and all the usual fundamentals of architecture. I've seen some folks suggest creating an SOA from the bottom up: look at a silo, identify the potential services, and publish them, then weave a system together from them. This is in essence technology first. In my experience, this is a recipe for disaster and/or serious over-engineering. You've got to start with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and there plan a flag for harvesting a meaningful service. These styles, and their resulting costs/benefits, are rarely discussed."
posted on Grady Booch's developerWorks blog on 2006 March 11, 2006
3/31/06 Updates to Resources for Architects: SOA Links
No sooner said than done! I just added a SOA Links page. It is just a starting point and I need to grow this page for there certainly is a lot more of use "out there," but I wanted a place to keep track of some of the links cited above, for example. I also added an architecture blogs section to the general architecture links page. I've been meaning to do that since Devon Stewart asked me to link to the IBM architecture bloggers.
I also write at:
- Bredemeyer Resources for Architects