Agile, Schmagile...

Here's an email I got from the Yahoo Business Analysis group I belong to:

From: "ginitram" <ginitram@yahoo.fr>
Reply-To: agileanalysis@yahoogroups.com
To: agileanalysis@yahoogroups.com
Subject: [agileanalysis] Article on Agile Adoption at British Telecom
Date: Wed, 26 Jul 2006 10:53:37 -0000
The Methods & Tools newsletter has just released in its archivesection the article "Agile Delivery at British Telecom". This articledescribes the approach used by British Telecom to move towards anAgile development process
http://www.methodsandtools.com/archive/archive.php?id=43

First, I recommend joining the group, it has a medium amount of intersting activity.

OK, here was my reply:

Hasn't this been published somewhere before? It looks familiar.

First, it's time that Agile proponents know that everyone gets it, smaller is better than bigger, delivery something on a regular basis is better than a big bang at the end of the project,... enough already. As I have said elsewhere, it's not that the waterfall is too long, it's that the river is too wide.

Ok, here are some snippets with my comments in brackets:

"Capturing requirements certainly isn’t a bad thing (well, duh). On typical large programmes however,
- Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release (sure, so the business must define the $ benefit of their pet requirements, while IT estimates the $ cost, and then present results in a cost-benefit analysis to the Sponsor, the one who is paying for the system, and it will be clear waht is in and out of the first/next release)
- "Gold users" generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed (same answer as above, plus if you literally get hundreds of requirements, declarative statements I presume, then you need to partition the project)
- Most if not all requirements are given a high priority (so rank them by highest return on investment)
- The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented (good analysis include stability analysis, documenting potential business changes and how the system will accomodate change. A systems' ability to incorporate change after delivery is also a requirement for all projects).

Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
-The requirements analysts move on to other projects, taking with them important tacit knowledge (this reflects poor documenting standards, all knowledge gathered by the Analyst must be documented.)
- Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs (what raises the stakeholders concerns? In any case, requirements are to be traced through design and into testing, so stakeholders really know what requirement is being supported where...)
- Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyses (this is scope management, the first evaluation of a change request is to determine if it is in scope or not. If it is in-scope, can it be added to the release without material impact on cost or delivery date? If not, this should go on a change request list for re-consideration in the next release.)

That's all I have to say right now...dww

New site for Requirements practitioners

The Requirements Networking Group at http://www.requirementsnetwork.com/

I have just had an article published on the site, and have started a new blog there as well. I am going to keep both going for now, with the new one re-publishing some of the material from this blog that is relevant to the site.

So, follow the link, join up and participate in forum discussions and blog responses and all that good stuff.

...in which Peter Coffee replies and we start an interesting conversation.

Peter C was gracious to reply to my slightly flammable email, starting with:

> Oh, and please give the word "Agile" back to the English language

It wasn't me who appropriated it...

- Peter

...which I answered with:

Yeah, perhaps I should re-direct that to Scott Ambler. The last time I saw him his advice to Business Analysts was "Learn how to code...".

My other question about Agile is technology selection: when do you determine that the new system will be developed with the technology at hand, presumably the languages and such that the programmers are already using? At what point does Agile say "maybe we should buy a COTS solution"? How does Agile recognize that the solution may not be new software but use of generalized infrastructure options like Workflow/BPM tools, or Business Rule Engines?

I have seen other writers' descriptions of Agile as falling into the characterization of "If all you have is a hammer, everything looks a nail". Thoughts on that?

..which he replied to with:

> At what point does Agile say "maybe we should buy a COTS solution"?

One of the principles of agile development is that "Simplicity--the art of maximizing the amount of work not done--is essential." I would certainly interpret this as implying that a team should consider available off-the-shelf packages, or externally hosted services, as preferable alternatives to writing new code.

> How does Agile recognize that the solution may not be new software but use of generalized infrastructure options

The Agile label's full expansion is "Agile Software Development," not "Agile Systems Construction." I see no reason why a systems development process that includes a development team following "Agile" practices could not also include a dynamic, collaborative uber-team that's looking at other options besides writing new code, but we should be fair to those who use the "Agile" label: they're trying to solve the genuine problem that writing new code is a task that needs to be done better, not the equally genuine but much more general problem that defining problems and developing solutions needs to be done better.

...which I liked very much, as it may clear up some confusion on the topic. I am going to reply with a follow-up, will post it later...

Today I give an Enterprise Architect some advice...

Greg Fullard is starting a series of articles about 'Business Objects" (conceptual ones, not the BI software) in Object Orientation at the IT Toolbox blogs,and he is a good writer. See:

http://blogs.ittoolbox.com/cio/modeling/archives/how-to-design-beautiful-business-objects-part-1-10718#

But he has a question I felt I could answer:
"Aren't these business objects that I keep talking about just the same as the Entities that my grandpa used to tell me about?"

The simple answer is... No.

Object Orientation has always been about producing better software, easier to maintain and primed for re-use. Entities, Relationships and Data Modeling in general has always been about producing better databases, usually (if not always) relational databases that eliminate data redundancy and are accessible without physical limitations (like old hierarchical DBMS's).

Where OO and Data Modeling look the same is their focus on key items of interest to the domain (business, government, non-profit, etc.), so good models will likely have the same-named things in them, like Customer. So what's the difference?

1) A Customer Class in OO is usually focused on one occurrence (Object) at a time, and the behaviors associated with it. A working OO system instantiates at object at some point, some methods (behaviors) are exercised, and then the object is gone. The only wrinkle on this is OO's recognition that some Objects are persistent, that they may be stored somehow and be used again.

2) A Customer Entity in a Data Model is usually focused on defining all the data attributes that need to be stored for any and all occurrences of Customer for the domain. As a blueprint for a relational table, the focus here is on managing many occurrences of Customer, as many as the domain needs to keep track of.

So, two different models, because they are two different things. The interrelationship between them occurs when a persistent Object needs to be instantiated; where do OO systems get that data? Far and way it is from relational databases, since I have not seen a (commercially) viable OO database yet.

So, two different models, and don't believe anyone who says a Class Model and a Data Model are equivalent, they are not... but you can derive a Class from an existing data model. Does anyone want to know how?

Today's post, in which I argue with Peter Coffee

Peter Coffee is waxing strongly on the benefits of agile development at:

http://www.eweek.com/article2/0,1895,1993420,00.asp?kc=EWITAEMNL072406EOAD

I know I am sounding like a broken record, but he asked for feedback by email, so this what I sent:


"As every good electrical engineer knows, the longer the signal path, the greater the parasitic losses due to inductance."…
An analogy that just rolls of the tongue… and has no relevance at all to the topic. Let's try another one: when I have my dream house built some day, I want to deal with the architect and maybe the overall contractor, I do not want to talk to the carpenters/bricklayers/plumbers/etc.

Business people do not want to invest time in software projects if they have to deal with the programmers; their respective frames of reference are so different they cannot communicate effectively.

That’s when a System/Business Analyst is needed, to get the business needs and develop the blue prints for the system. S/B Analysts speak both languages, and are the interpreter between the business and the programmer.

Why does agile have to react so well to change? Because the programmers did not hear what the business wanted in the first place, so odds are the software will be wrong. The SOFTWARE has to change because it is wrong, not because the business changed.

Oh, and please give the word "Agile" back to the English language; agility is not restricted to one methodology. Call yours "Programmer-Driven Development", no one can argue with that name.

David Wright

Comments, anyone?

Business Analysis / Architecture "Quote of the Day", 20/07/2006

"Today, with the Zachman Framework as a foundation...we now know that if two people discussing a prospective system cannot understand each other, it is probably because each is operating in a different cell of the framework. Neither professional is necessarily incorrect or incomplete, but simply viewing the same problem space from a different perspective"

... Barbara van Halle, from her Foreword to 'REQUIREMENTS ANALYSIS: From Business Views to Architecture' by David C. Hay (Prentice-Hall, 2002)

That book on Requirements Analysis was just delivered...

"Requirements Analysis: From Business Views to Architecture" by David C. Hay.

I have just finished the Forwards and Introduction, and I believe Mr. Hay may have already written the book I have thought about writing myself (assuming one can actually write a book just because you want to...).

I could wax on about specific quotes and lines of interest, but the Introduction is excerpted in full at amazon.com ("Look Inside The Book"), along with the Table of Contents, so I recommend all Business Analysts go to Amazon and read it... and then I am sure you will want to buy the book.

http://www.amazon.com/gp/product/0130282286/ref=si3_rdr_bb_product/104-5814185-0628700?ie=UTF8

Why is this a book I wish I had written? It is not a sales pitch for any one methodology, it is the sum experience of a working Business Analys/Consultant who has seen ALL the methods and models out there, now and in the past, and has taken Zachman's Framework and populated all the row 2 and 3 cells with all the Artifacts one might use; and then he sweeps across the columns speaking to all the artifacts and how you might use them. He emphasizes that the Data and Activity columns have the most artifacts, because that is where most of the analysis work has been done over the last 30 years; but he then states he is going to keeping moving to the right to those columns where not many have gone before, all the way to Motivation, and mentions some artifacts that will be unfamiliar to most people ("filters", "attenuators?").

So, on to Chapter One: "A Framework for Architecture"...

Business Architecture?

My past experience has included stints as an 'Architect', rather than 'Analyst', and one of those titles was truly involved in Architecture, with a focus on Models and the Zachman Framework.

That was a few years ago, but I was recently asked for my views on what "Business Architecture" is, and here is what I wrote:

Three key aspects of Architecture:
1) It is not an end in itself; Architecture exists because things need to be built.
2) Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
3) Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

The most common and oldest form of architecture is construction of buildings: dwellings, work-places, etc.. The need for Architecture arose centuries ago when construction failed or the end result collapsed. All of the above three aspects are inherent in this field: the known and desired end product, defining and integrating all components needed, and the layering: from a high-level floor plan, to blueprints, to wiring diagrams and other detailed specifications.

A Business, any Business, has the same need for Architecture, and presents further challenges than constructing a building. Buildings are complicated, being made up of many pieces that have to fit together, but they are finite; you can count and describe all the pieces which will be in place when the building is complete. A Business, and really Enterprises of any kind, are complex, meaning that they change over time; pieces may be re-arranged to fit together in a different way (e.g. org chart re-organizations or process improvements), and some pieces may be revamped or enhanced (like Information Systems), while other pieces are retired/discarded and new pieces added to the Enterprise (like Equipment).

In the end, the most commonly identified pieces of an Enterprise are its resources (people, capital, raw material) and the systems/processes that use the resources to produce an end product or service. Enterprises use many different kinds of systems in their operations, many of which are highly cohesive and de-coupled (their relationships to other pieces are few and well-defined), e.g. different assembly lines of a manufacturing company.

On the other hand, Information Systems used by an Enterprise in support of its operations increasingly need to be aware of the full scope of the Business, across all resources and processes. This presents its own Architectural requirements, such that a complete, all-encompassing Enterprise Architecture for Information Systems is needed, if systems and technologies (the “pieces” of the Information Systems) are to built/acquired, deployed and used effectively, without the redundancy, duplication and inconsistency of information systems delivered in the past.

Architecture within a discipline comes to depend on common practices and standards over time to increase efficiency and eliminate unnecessary re-invention; it is commonly stated that Information Systems delivery as a discipline is still too young to have developed such commonality, but work has begun, notably by John Zachman and his and his Enterprise Architecture Framework of the late 1980’s.

See http://www.zifa.com/ .

Here are your Resources (the columns) and your layered views (the rows) that will take a Business from its highest-level context through to functioning Information Systems.

They key row to me is Row 2, the Business Model. Row 1 provides, as its says context/scope. It is very important to understand the scope/boundary of the Enterprise for which the architecture is being created, especially when large Businesses define themselves as being constituted of multiple ‘Enterprises’. Once that is defined, which should not take very long, the critical development of the Row 2 Business Models can proceed; these must accurately represent the in-scope enterprise/business at a detail level, otherwise the remaining lower rows (where most of the money is spent) will not lead to building the right Information Systems for the Business.

Finally, Zachman always states that he has defined a Framework, not a methodology to populate the cells, or define what types of models should be used. Given the framework, different methods/models can be used for creating (and communicating!) an Enterprise Architecture for a Business, often with a focus on accelerated or prioritized delivery; most owe some debt to the original Information Engineering developed by Finklestein in the 70’s and popularized by Martin in the 80’s. The key point here (and the last one in this dissertation) is that it does not matter which methodology you use, as long as you pick one and use it for all it is worth, both to create systems, and as a language common to all participants in the Systems Delivery Process (SDP).