Enterprise Architecture

Lets say there's a development requirement to treat data differently if a date in a db row is before May 1, 2011. Specifier swears a blood oath that that date will never change.

So you can:

if someDatabase.myDataField < 05/01/2011 ...

But if you have a little experience with specifier's blookd oaths, you know that can't be counted on so you do:

GlobalSingletonObJect file:
myGlobalSingletonObject.splitDate = 05/01/2011

In some code elsewhere:

if someDatabase.myDataField < myGlobalSingletonObject.splitDate ...

And if that same rule gets applied elsewhere, all relevant statements refer to the global object property setting, not a bunch of literals buried in code.

Okay, we all know that. Already.

But now imagine the same concept being applied to an entire enterprise architecture. So that the ability for the business to change course, speed up, and extend itself is built into the enterprise architecture design.

This kind of scalability can be done without a lot of excess expensive foundation work, because only the possiblity of change is built into the applications, platforms, vendor selections, requirements, databases, hiring, etc.

Allowing for change can be architected almost for free - except you have to pay the architect :) . And I did say "almost", so maybe it could have a 3 - 5% add-on cost.

Like when you name a file, device, version, or etc. like this:

myplan.txt

or better:

myPlan1.txt

or

myPlan01.txt

but of course myPlan00001.txt is a waste of keystrokes, but by how much?

Same thing but with the overall architecture of information technology for a company or product.

The Lean Startup

The Lean Startup by Eric Ries

Eric put together and moderated the recent conference, "Lean Startups: Lessons Learned" in San Fran, simulcast in major cities including LA (Santa Monica), which I attended. It was an awesome day with very information density.

This book comes out in September of 2011; prior to that it can be pre-ordered.

This link is the Kindle edition but it's also available in paper.

The Lean Startup

The Four Steps to the Epiphany

This is Steve Blank's major book, who is one of the gods of Lean Management (Lean is Agile applied to management):

The Four Steps to the Epiphany

Business Model Generation

This is the current latest hot methodology in startup creation.

The book is here at Amazon:

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers

Business Model Canvas

The Business Model Canvas is the alternative to income statements and balance sheets, which are meaningless at startup companies.

Part of the Lean methodology, which is Agile applied to companies, ie Enterprise Architecture.

Wikipedia entry for Business Model Canvas

Is management support needed to use an Agile methodology?

Question: What kind of support do you need from management (or your client) in order to start using an Agile Process?

Okay, here's a contrarian answer:

I DON'T BELIEVE THERE IS ANY BUY-IN OR SUPPORT NEEDED IN ORDER TO APPLY AGILE!

Agile is a competitive advantage in and of itself. (If it wasn't, why bother? Surely not only because "Agile good, waterfall bad".)

The business environment itself demands agile because it is changing rapidly, and agile is the winning response wherever the cost of doing/redoing/re-re-doing (agile) is less expensive than perfecting the design before doing anything (waterfall).

The pyramids weren't built using agile methodology because they couldn't pile up a bunch of 10-ton stone blocks and then move them around until they got it right.

But almost all knowledge-based projects (such as software) are different using today's tools.

So let's say a client wants me to create a fat binder of exacting specs before writing software (ie traditional waterfall). I can't make the project agile, but I (and whatever team or part of it I'm with) can iterate those specs instead of taking notes for 6 months and then dropping off the fat binder. I can also do metrics on how the requirements even for already communicated specs are changing, and thus show how that fat binder is always going to be x% of date with y effort devoted to updating them, where that x% drops off as the y effort is increased, but with diminishing returns.

Sure, it would be even better if I can convince the project drivers that building a prototype that users can verify would be even better than than the book alone, but if I can't convince them, I can still deliver whatever result I'm committed to, with the resources I control, in a greatly advantageous and competitive way.

My point is: you can always run your little corner of the world very successfully in an agile fashion.

Coming soon...

Agile To Go is a ready-made system for applying Agile today, with document templates and planning schedules all ready-to-go.

Agile To Go (tm) Tech III, Inc. 2009

All content copyright (c) 2009 Tech III, Inc.