A White Paper you have to pay for
|
|
The concept of 'brownfield' is interesting in IT, given a lot of effort nowadays is around big projects in legacy contexts. This book is certainly about big projects (200 man-years plus). Unfortunately it says next to nothing about the many complexities of such projects. Instead it seems to be covering an IBM product/proposition called VITA. You won't see it on their site but it looks like they've employed this approach on client sites. The general idea is you capture all sorts of information (specifications, code, diagrams, UML, spreadsheets, interfaces etc) and roll them into a single massive database of simple sentences ('semantic triples). You then derive all sorts of artefacts - from diagrams to code - using "transforms" or "patterns". It is model-driven except it uses XML, XSLT, Eclipse, RSA, RDF, OWL etc rather than proprietary schemes. Does the book give a single example of how this is done? No. Who knows - IBM may be onto something that will change the world but at the moment it is all based on faith - there's no practical description of how you might achieve these magical aims, let alone the strengths, weaknesses, theory, practice etc. This is just a very (very) lengthy white paper that hardly tells you anything.
|
|
An important step change in how to approach IT delivery
|
This book is an excellent introduction to Brownfield IT development with a realistic approach to moving to its vision. The book is well written and very easy to read - I managed to digest it easily in four train journey sittings over three days (pun intended).
I am a colleague and friend of Kevin and Richard. I have worked with them on engagements in the past, including those adopting Brownfield techniques. I can honestly say this book is based on real IBM experiences with our customers. We are fortunate in our business of engaging many different types of customers with many different IT environments. We get to see the recurring problems they face and frequently see IT practices that resonate strongly with the problems laid out in the book. It clearly lays out the vision and solutions to the problem.
I wholeheartedly recommend that if you are an IT executive and technical leader who grapples with a multitude of IT projects that you read this book. By page 41 you can associate with the authors and the problem statement from which the Brownfield vision emerged is obvious. By the time you are racing through Part II you will be thinking about how you can adopt Brownfield techniques in your particular context.
|
|
|
Real innovation in very large IT system implementations
|
Eating the IT Elephant is a description of how the authors have thought their way through, and built a solution to resolve, the problems of designing and delivering massive IT systems implementations in a "brownfield" site. Brownfield describes the environment that exists in every real business - the constraints and complexities of the current "legacy" systems, those that any new development must co-exist with, either during its implementation phase, or more likely through its life. Brownfield contrasts with Greenfield - the illusion that new IT developments can be built as if there were no problems in "the site" to contend with.
It describes the problems of elephantine systems projects: how communications with business stakeholders is crucial, but generally attempted by simplifications and abstraction; how impossible it is for any one head to contain the complexity of the requirement and the current environment constraints; how separate teams of business analysts and architects cannot adequately communicate their view of the ever-changing landscape to each other; how the paper mountain of business and process models, architectures, requirements and work products grows inexorably, with little likelihood of consistency and coherence.
The authors, both young currently practicing IBM IT Architects, contrast this with the toolset they have assembled during their experience of massive systems delivery; quite simply an Elephant Eater, a tool that voraciously consumes every requirement, model, architecture, constraint and site survey result on the project and maintains it in an inventory of massive simplicity, but all-encompassing completeness. This tool, which consumes all varieties of open system definition tool outputs, and even legacy program code, can deliver daily iterations of the "single version of truth" in outputs which can be of value to all participants, whether they be business sponsors, programmers or implementers.
This constant availability of the current state of play allows iterative testing of requirement completeness, system and architectural integrity, highlighting where inconsistencies lie and where new input is required.
Once the reader has grasped the idea, and the methods are described, it is easy to understand how the authors believe there is now a much greater chance of successful delivery of elephantine developments than ever before. Grasping the idea is not difficult; the book is not written with only the system developer in mind. It is full of good mental images and written with humour and eloquence very rare in the architect's profession, in my experience.
I commend it to everyone who has an interest in the successful delivery of very large IT systems.
|
|
|
United States | 
United Kingdom | 
Canada