On this page.... RSS 2.0 | Atom 1.0 | CDF
# Saturday, 12 April 2008

In his article, "Who Needs an Architect?", Martin Fowler says:

At a fascinating talk at the XP 2002 conference1, Enrico Zaninotto, an economist, analyzed the underlying thinking behind agile ideas in manufacturing and software development. One aspect I found particularly interesting was his comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility—as opposed to tackling other complexity drivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

How interestingly this melds with my recent thoughts on managing complexity.2 You see, adding processes, management systems, and "governance" in general makes things more ossified, more difficult to change, i.e., less reversible.  According to Zaninotto, this would mean that the more governance we put in place to, theoretically, manage the complexity of our software systems, the more complex they are bound to become, which I think logically means that we are increasing our complexity woes rather than helping them through such efforts.

I came across this in a recent thread on our (now-retired-)architect MVP email list, where the age-old discussion of "what is an architect?" has come up again.  I have to admit, when I first seriously confronted this question, I was drawn in and fascinated.  I even wrote an article about it on ASPAlliance.3  Since writing that, I've been keeping an eye on the developments at IASA and elsewhere in this space, and developing my own thoughts.

I've delved even more into agile approaches, particularly Scrum and domain-driven design (DDD), and into this thing we call "user experience,"4 which at first glance seems counter to our architectural/engineering approaches to building software.  I've gained more experience building software as an architect and manager and observing software being built at the commercial level.  I've been more involved in the business and marketing side of things, and I've been blessed with the opportunity to learn from some of the leading minds in our profession. 

At this point, I'm of the get 'er done school, which I suppose might map loosely to Fowler's Architectus Oryzus, Eric Evans' Hands On Modeler, and others along those lines.  I'm bought into User-Centered Design (or human-centered design, for those who prefer that), though I think we need to figure out a good way to merge DDD with UCD and a smattering of service orientation (as needed!) to make software the best it can be.

Software is complex enough without our making it more so with artificial taxonomic and gubernatorial schemes.  Software should be teleological by nature.  It exists to serve an end, a purpose, and if it isn't serving that purpose, the answer is not to create counterproductive metastructures around it but rather to make the software itself better.

One of the chief complaints about IT is that we seem resistant to change or at least that we can't change at the speed of business.  Putting more processes, formalization, standardization, etc. in place exacerbates that problem.  The other biggie is that software doesn't meet the need it was designed to meet.  Both of these, at their core, have the same problem--ineffective and inefficient processes that are put in place to manage or govern the project.

I tend to think that projects need managing less than people need managing or, rather, coaching.  You get the right people, you give them the equipment, the training, and the opportunity to do the right thing, and you get out the way and help them do it.  You don't manage to dates (or specs!); you manage to results.  If you don't have a solution that meets or exceeds the need at the end of the day, you failed.  In fact, I might go as far to say that if what you built matches the original specs, you did something wrong.

Any managerial involvement should have a concrete and direct end in mind.  For instance, coordination with marketing and other groups requires some management, but such management should be communication-oriented, not control-oriented.  Start small and evolve your management over time.  Management, like other things that are designed, is best evolved over time5 to meet these concrete, real needs--and you should keep an eye out for vestigial management that can be extracted. 

Similarly, I don't think we need to tackle the software (IT) profession by trying to define and stratify everything we do.  In fact, I feel it would be a rather monumental waste of our collective valuable time.  One thing is certain, our profession will change.  New technologies and new ideas will combine with the rapidly changing business needs, and new roles will emerge while old roles will become irrelevant (or at least subsumed into new roles).  Monolithic efforts at cataloguing and defining (and by extension attempting to control) will, in the best of all possible worlds, be useful only for a short time.

It's clear that there are many approaches to doing software.  It's axiomatic that there are many distinct, even unique business needs (inasmuch as there are many unique individuals in the businesses).  What we should be doing, as a profession, (indeed what I imagine and hope most of us are doing) is focusing on how to make great, successful software, not wiling away our lives and energy talking about ourselves. 

If you ask me what I do (e.g., on a demographic form), I tend to put software maker, or just software.  Obviously, that's not specific enough for hiring purposes.  But really, in hiring, we're really looking for knowledge, experience, skills, talents, and attributes, not a role or title.  A title is just a hook, a handy way to get someone interested.  If the market shows that using "architect" in a title catches the attention you want, use it (whether you're a worker or looking for workers).  The job description and interview process will filter at a finer level to see if there's a match.

Outside of that, we don't really need to spend a lot time discussing it.  We're all just making software.  We all have unique knowledge, experience, talents, skills, and attributes, so there really is very little use in trying to categorize it much beyond the basic level.  So how about we stop agonizing over defining and stratifying "architecture" and "architect," stop worrying about controlling and governing and taxonomifying, and instead invest all that valuable time in just doing what we do--better!?

Notes
1.  More at http://martinfowler.com/articles/xp2002.html.
2. See One System to Rule Them All - Managing Complexity with Complexity and Software as a Biological Ecosystem.
3.  Read "What is Your Quest?" - Determining the Difference Between Being an Architect and Being a Developer.
4.  Good place to start: http://en.wikipedia.org/wiki/User_experience
5.  This principle is discussed, for example, in Donald Norman's Design of Everyday ThingsChristopher Alexander also discusses a similar principle in The Timeless Way of Building.

Saturday, 12 April 2008 16:06:39 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
Comments are closed.

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2017 J. Ambrose Little