Architecture @ New Myths

I attended a talk by Scott Ambler today where he covered a number of growing pains in the Agile Development community. Particularly of interest was the observation that the agile methodology is not independent of modeling - particularly requirement and architectural modeling. Scott really drove into this point fairly thoroughly for the time alloted, but its something that many organizations should keep firmly in mind. Being agile doesn't mean ignoring the proper setting of direction.

Now the interesting question should be: how do organizations take requirements and architecture and bring some of that agile methodology to these disciplines as well. Take requirements modeling for example:

• User Stories - most of us know that user stories are great, but they don't really tell the whole story; really, they just tell the user's experience, not the needs of other stakeholders who have equally valid needs
• Operational Scenarios - user stories for the operations folk; this can be a lot of fun - how can things go wrong and what do we need to support these scenarios; this is really dependent on having people who can really think in mean and nasty ways about things that are supposed to work normally
• Quality Capabilities - this refers to the "ilities" that make our systems worth using; our experience has shown that these are best fulfilled through some basic scorecard structure (we also recommend throwing this at your architects or operational folks)

What about those architecture guys?

• Strategy - architecture really needs to be responsible for projecting out and explaining where the development is headed after the first major iterations; this doesn't need to be grandiose or full of detail, but it does need to clearly articulate major concepts and changes from initial direction
• High Level Design - this really needs to occur at what we call the "box and pipes" level; nothing as rigorous as UML, but just a basic indication of the players and why they are needed (if you're going below the component level, you've gone way too far)
• Standards - this one seems obvious, but we recommend a slight change to the norm: don't develop all-inclusive standards; instead, focus on the bare minimum needed that everyone will have to bide by in order for development to be orderly and without conflict (this, like many things in agile requires a bit of experience)

Working on a major effort as part of my day job and I was asked about the biggest risk in a particular environment. During the course of discussing it, I tripped upon a theory of architecture - not exactly rocket science, but it occurred to me that no one ever articulates these things (or even really attempt to prove them - we simply accept them as lore), so I decided to make a point of documenting the obvious (something I believe falls squarely within the architect job description).

Any way, on to the theory:

Theorem: Given any technology environment, when the ratio of business functionality to the overall number of systems favors business functionality, there is a positive relationship to the cost and complexity of the environment.

Corollary: When the ratio favors the number of systems, there is a negative relationship with the cost and complexity of the environment.

I've purposely used relatively non-mathematical language as this approach presents a few problems:

• How do we measure "business functionality"?
• How do we normalize the business functionality measurement with the number of systems?
• How do we define the terms of the relationship between the ratio and cost/complexity?
• How do we define complexity in mathematical terms?

Regardless, it seems that this is a grand example of the "folk wisdom" that many architects believe, but never write down. All said and done, this somewhat calls out for a calculus of architecture (wasn't Djikstra working on a calculus of algorithms prior to his death?).

I'll be speaking at Dr. Dobb's Architecture & Design World at the end of this month in Chicago (topic is Legacy SOA - basically a primer on how to implement SOA in a complete, heterogeneous environment as opposed to homogenous new development). If you're in town, drop me a line.

As part of a larger effort to identify the role, skills and practices of the various types of IT architects, I have assembled a survey to collect feedback from people currently carrying the title of "architect." The survey itself is relatively short (30 minutes was the average during testing) and is designed to hone in on the skills and responsibilities of various architects in their current jobs. If you are currently working as an architect, please take the time to complete the survey. No information of a personal nature will be collected during the survey and cookies will only be used to help ensure that the survey is only taken once (no personal information is embedded in the cookie).

If you are eligible and interested in taking the survey, please click here to begin.

The agile craze has struck my workplace (seems to strike about once a decade) once again and is creating problems for the architectural engagement process we put into place so long ago. In response, I started looking back at the history of architectural processes and was struck by the general lack of agility - even in those that were founded amidst iterative processes (I'm talking about you Rational!). I've thrown out a strawman at work that seems to fit the bill for our use, but I may dress it up a bit and post here if it takes off.

I've been working on a new concept for a presentation involving the practicality of BPM for small businesses when I came across this blog posting at JBoss' site. Now everyone is entitled to their opinion as we go about figuring out how to apply these new technologies, but this one really struck me (I was a bit frustrated at the time - I had just finished getting JBoss' BPM package up and running - an absolute joy). I appreciate the point of the post, but its so woefully aimed at IT that its not even funny. BPEL is an integration technology, but that is EXACTLY what makes it a BPM collaborator. BPM by itself is just a bunch of fancy diagrams with code generation at best - explain it to any business partner and watch the yawns begin. Now, throw in a bit of BPEL to link those shiny services with your shiny business processes and take a look at what you get - real flexibility and agility in the development process. Not poorly generated code, but a truly dynamic business environment. That, my friends, is a winner with the business because it delivers tangible, business value - not just another technology toy. In my opinion, if this position is truly representative of the view of JBoss, then they might as well get out of the business and leave the others who are adopting this more complete mentality (IBM, BEA) to continue to dominate the field.

Looks like I'm headed back to Chicago to revisit the topic of Legacy SOA enablement. I'm pretty excited overall - I think its a great topic and its easily one of my favorite talks to give. The A&D World website seems to be down for updates, so you'll have to wait for the full agenda. See everyone in Chicago!

One of the things that I've struggled with is the whole BPM thing. I've discovered over time that most people agree on what the BP part means, its the M that seems to hang people up. So, as I'm prone to do, I took a stab at describing how I see the M in BPM - both holistically and individually. Without further ado, M stands for:

• Modeling - Describing the business processes and understanding how they work together to accomplish the client process
• Management - Is the act of coordinating business processes and aligning/mapping the business models to the associated implementation(s)
• Monitoring - Tracking and understanding how processes are executing and the state of data flowing through the processes

The magic happens when you tie them altogether. You suddenly get the ability to create a full process lifecycle - understanding the business, operationalizing it and finally optimizing it as you see it in practice. Does it all work out in practice? Somewhat. LIke anything of this sort, BPM requires a real shift in the mentality of those undertaking the practice. Without shifting the culture, successes tend to be spotty, based around resources who are able to spot and subsequently take advantage of optimization opportunities as they arise (which should be easier to do with the right tooling, but that's a discussion for another day).

So I've been thinking lately - what happens when maintenance costs increase at a consistent, unchecked rate? After all, the general consensus, is that over time, costs increase in successful businesses as greater capabilities and capacity are required. Now the observant reader will opine that if the business is increasing in success, shouldn't the profits be reinvested? I'll acknowledge that as a possibility, but would argue that its rarely, if ever, at a level where it is proportional to the increase in cost - particularly if inflationary pressures are taken into account. Now the interesting part is what happens if the above is all valid - as illustrated off to the side - you eventually experience a period where maintenance is so great, that it begins to impact the funding allocated to new efforts.

I've been reading a number of "strategy" books lately and there's an idea that sticks out with regards to all this - if you're forced to spend money on maintenance, then your thinking on initiatives becomes more tactical - the business begins to assume that innovation can't take place and stops planning for it. The result is a self-fufilling prophecy that eventually leads to an eventual downturn in the business that worsens the situation further.