The aforementioned Dick Gabriel posed a question to the Hillside Group: what is design? Here's my reply to him:
As a noun, design is the named (although sometimes unnamable) structure or behavior of an system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions).
As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness).
A few related terms:
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
In any given genre of systems, the same designs are found again and again. Insofar as we can name these designs and codify them in a relatively general fashion, they are the patterns of that domain.
Sometimes we will speak of a particular style (or school) of design. A style is a named collection of a set of designs that is observably identifiable from other styles.[Read More]
Software architecture, software engineering, and Renaissance Jazz
From archive: March 2006 X
I just returned from some work with the SEI in Pittsburgh and then in Washington, DC where I conducted a number of customer visits primarily focusing on service oriented architecture.
Comments about hunting with Dick go over really, really well with the DC crowd.
My take on the whole SOA scene is a bit edgier than most that I've seen. Too much of the press about SOA makes it look like it's the best thing since punched cards. SOA will apparently not only transform your organization and make you more agile and innovative, but your teenagers will start talking to you and you'll become a better lover. Or a better shot if your name happens to be Dick. Furthermore, if you follow many of these pitches, it appears that you can do so with hardly any pain: just scrape your existing assets, plant services here, there, and younder, wire them together and suddenly you'll be virtualized, automatized, and servicized.
SOA is, first and foremost, about the A part of the acronym (architecture). Organizations who already have a solid approach to architecture will likely do reasonably well with SOA; organizations who already have a broken architecture and/or a broken architectural governance practice will likely fail with SOA and then blame SOA on all their problems.
If you follow the history of web-centric systems, services (with a small s) are a very logical progression of web mechanisms. From a technical perspective, SOA is nothing revolutionary, it's evolutionary. BTW, in this context, the concept of an enterprise service bus can be easily explained as a very elegant and simple pattern for location independence/message translation.
There are places where SOA is suitable, and places where it is not. SOA, from my experience, is one specific architectural style appropriate for systems of systems wherein some but not necessarily all of those systems are already web-centric. This is an important point: SOA is a useful but insufficient mechanism for architectural decomposition. Some would suggest that SOA is all you need. This is seriously wrong.
To that end, services (with a small s) are best suited to relatively large grained/low frequency interactions rather than small grained/high frequency interactions. For that latter situation, other, more traditional, mechanisms of RPC and/or message passing are better suited.
A serious gap in the current state of the art of services is that we simply don't know how to specify quality of service very well at all. It's one thing to wire together services a la National Instrument's LabView, it's another if there are quality/performance/reliability/security/dependability issues for each of those channels and each of those ports.
There are also services with a big S: there is a conceptual kind of service that is not manifest as a pure WSDL service but rather something else. Think of a service as a port on a system, with that port having a well-defined interface consisting of a vocabulary of classes, a protocol, and a particular set of messages and resulting behavior. It is a good thing that you can conceptualize a system as a web of services, some of which are Services and some of which are, well, services.
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.
In a couple of weeks, I'm off to a very different venue, where I'll be giving a talk at the Game Developer's Conference in San Jose. Developing software for games is big business, and this community is starting to discover that the fundamentals are important: you can't build an enduring a business just by hiring bright people, throwing them in a room together, and hoping that they'll do great things.
But, enough about Google...[Read More]
I just finished my gig at the Game Developers Conference in San Jose.
What a kick this was! The gaming community is incredibly vibrant and full of innovation. A number of people and journalists (ok, journalists are people too, please don't get me wrong) asked me why IBM had such a large presence and why I was there. As for IBM, do recall that the cell is what powers every new generation console, so not only is there the obvious hardware play, there's also a tools play and a data center play (consider the computational power needed to support a large online multiplayer game). As for me, gaming architectures are themselves quite interesting and worthy of study, plus this is a community that's at an inflection point of embracing the fundamentals of sound software engineering practice, encompassing architecture, patterns, process and all the other topics of which I'm passionate.
In addition, this is one of the few software-intensive domains wherein fun is an essential use case.[Read More]
gbooch 120000P81R 947 Views
I struggled with this post. On the one hand, I'm not trying to cast stones at Microsoft; on the other hand, there are some deep lessons to be learned from Microsoft's slip of Vista. Every organization attempting to deliver a continuous product stream in the face of considerable legacy code and a large installed base will confront these same issues. Those who break through these issues will persist; those who do not will collapse.
Mini-Microsoft, a Microsoft developer, recently posted his reaction to the Vista slip. A number of other (anonymous) Microsoft developers posted additional comments. While many of these postings are full of noise and exhibit angst suggestive of considerable organizational frustration, if you blow past those you'll see some interesting trends: the lack of architectural governance, uncontrolled feature creep, insufficient testing, heavyweight processes, lack of trust in the engineering staff. I particularly liked one comment: "Want to see Vista ship? Get rid of 90% of the process that goes between writing the code and getting it checked in." Colllectively, these comments suggest that the root problems are not technical, but rather orbit the region of design and organization in my characterization of the limits of software.
IBM is a company that has experienced a near-death experience and has thus far been able to break through to the other side; Microsoft seems be going through a bit of a mid-life crisis; Google is perhaps best characterized as an exuberant adolescent who has not yet discovered his mortality or limitations.
That's not to disparage any of these organizations: the fact that this marketplace has such a diverse set of organizational styles at various levels of maturity is actually the sign of a vibrant industry.[Read More]
gbooch 120000P81R 860 Views
gbooch 120000P81R 806 Views
gbooch 120000P81R 795 Views
The other day, Steve Mellor asked this question of the IEEE Software board, and I replied:
In the coming decade, both of these statements will remain true
gbooch 120000P81R 783 Views
gbooch 120000P81R 702 Views