Erik on Software

New Book Review: "To the Cloud"

New book review for To the Cloud: Cloud Powering the Enterprise, by Pankaj Arora, Raj Biyani, and Salil Dave, McGraw-Hill, 2012, reposted here:

The authors of this text rightly explain in their introduction that the path to cloud adoption is bound to be different for every firm. Because much of what is provided here is based on Microsoft IT's own experience with cloud adoption, and most of the software that Microsoft IT consumes is built in-house, the authors point out that they recognize their enterprise is unique, so they chose to focus on concepts rather than specific technologies when guiding the reader through the cloud adoption learning process. While the reader should readily recognize that this is a Microsoft text because the foreward was written by Microsoft CIO Tony Scott, what the authors present here is for the most part product agnostic. And since they share as case studies what they have accomplished as Microsoft IT, it should be no surprise to readers that Microsoft Hyper-V and Windows Azure are periodically mentioned.

The material presented here is broken down into four parts: (1) Explore, (2) Envision, (3) Enable, and (4) Execute. After first discussing the cloud computing paradigm, and the value proposition that it offers, the authors provide practical advice for developing a business case and building consensus with key stakeholders once there is momentum in making a move toward the cloud. The following focus then shifts to various adoption approaches, and a number of topics surrounding cloud execution. Having also just recently completed a reading of "The Cloud at Your Service: The When, How, and Why of Enterprise Cloud Computing" by Jothy Rosenberg and Arthur Mateos (see my review), another high-level introduction to cloud computing that follows a similar line of presentation, as a consultant who works with technical and non-technical stakeholders I see the need for these two texts to share the same shelf space, with this other work catering to a technical audience.

In my opinion, what Arora, Biyani, and Dave provide here is akin to an expanded white paper, due to its format and sub-100 page length, perfect for mid-air reading. One aspect of this text that I especially appreciate is the well executed style of diagrams reminiscent of Harvard Business School Press offerings, which always provide ideas as to how the material might best be presented visually to a non-technical audience. Judging from the frequency and location of dog ears that I left behind after my reading of this book, I found the first half of what the authors present to be material to which I will return, with the parts on Explore and Envision especially well done. The section on "demand patterns", for example, in which the authors describe application usage patterns used to determine best fit based on analyzing user demand and usage patterns, as well as workload characteristics, although brief, was surprisingly not covered as a topic in the earlier work. Well executed. Recommended especially for non-technical management.

New Book Review: "The Cloud at Your Service"

New book review for The Cloud at Your Service: The When, How, and Why of Enterprise Cloud Computing, by Jothy Rosenberg and Arthur Mateos, Manning, 2011, reposted here:

Potential readers of this text, especially those familiar with Manning, might be interested in knowing that in their preface, the authors indicate they "had to convince Manning to publish a book that wasn't aimed squarely at programmers. When we told them the book had no source code, that didn't compute. We held firm, arguing that a huge need exists for a book that tells it like it is for the enterprise IT worker. The cloud will eventually have its greatest effect on the largest of organizations. But they're precisely the organizations that have the most trouble changing. We wanted to talk directly to you about how to undertake this shift, what it will mean to you and your organization, and how to proceed in a sane and reasonable manner."

The authors are correct that this need exists, and after reading what they have to offer here, this space will continue to need additional contributions for quite some time. As a consultant leading a virtualization project this past year, a prior reading of this text would have helped prepare me for some of the discussions that ensued with client personnel. While technical texts such as "VMWare vSphere 4" by Scott Lowe (see my review), significantly increased my confidence at a product level, the periodic conversations surrounding what can be seen as a possible next step following virtualization, use of a cloud, could have benefited from materials like the authors provide here, because quite simply there are very few product neutral, cloud focused texts.

The authors actually do provide some source code, however minimal, in this text, but it is mainly confined to what Amazon provides with its cloud API. Some code snippets from competitors such as Microsoft are also provided for contrast, even though the authors indicate throughout the text that Amazon leads the pack and predict that Amazon will continue to lead in upcoming years, mainly because Amazon got to the starting line earlier due to providing to the public what it first had utilized solely for internal solutions. The first few chapters, entitled "What is Cloud Computing?", "Understanding Cloud Computing Classifications", "The Business Case for Cloud Computing", "Security and the Private Cloud", and "Designing and Architecting for Cloud Scale", together with the concluding chapter, "The Future of the Cloud", were well done, but chapters "Achieving High Reliability at Cloud Scale", "Testing, Deployment, and Operations in the Cloud", and "Practical Considerations" feel at times rushed or out of place.

The target audience of this book is probably greater than what the authors surmise, which is to say that regardless of whether protential readers are managers or programmers, anyone interested in quickly getting up to speed with some of the core tenants of cloud computing can probably benefit from this book. As a consultant architect, I especially appreciated the persistence of the authors throughout the text of focusing on the five main principles that define cloud computing (pooled computing resources available to any subscribing users, virtualized computing resources to maximize hardware utilization, elastic scaling up or down according to need, automated creation of new virtual machines or deletion of existing ones, and resource usage billed only as used). In addition, the authors present the high-level business and architectural cases for cloud computing well.

New Book Review: "IBM WebSphere DataPower SOA Appliance Handbook"

New book review for IBM WebSphere DataPower SOA Appliance Handbook, by Bill Hines, John Rasmussen, Jaime Ryan, Simon Kapadia, and Jim Brennan, IBM Press, 2008, reposted here:

A couple months ago, I read through this near 900-page text in preparation for the project I am currently leading to move my client from proprietary software built in-house to a suite of WebSphere branded products that includes DataPower. While the scope of the project ended up changing to exclude work on DataPower, the background that this book provided was immensely valuable in getting an understanding of the client product environment from both an architecture perspective and an in-the-trenches development perspective.

Prior to reading this text, I read through other material such as Parts 1, 2, 3, and 4 of the IBM RedBooks series "IBM WebSphere DataPower SOA Appliances", but even though IBM RedBooks provide valuable information, and I regularly reference both IBM product manuals and IBM RedBooks while working with the rest of the WebSphere branded suite of products being used for this particular project, such as WebSphere Message Broker Toolkit and WebSphere Transformation Extender Design Studio, I find this book much more practical for DataPower.

While I extolled the benefits that vendor neutrality provided another IBM Press text, "Enterprise Master Data Management: An SOA Approach to Managing Core Information" (see my review), what the authors provide here is intended to focus on DataPower, and additional non-IBM background material is provided to both those new to this space and those who need to get acquainted with the particular contexts in which DataPower might apply.

My focus was on the DataPower XI50 integration appliance, although this text also covers the XA35 entry level product and the XS40 security appliance. The Chapter 1 introduction to appliances and the DataPower family outshines all of the presentations found readily via search engines, including those from IBM, and the coverage of DataPower setup, configuration, networking, services, management, and security literally starts from square one. The best practices and insight you will not find from any other printed material is what sets this book apart. Well recommended.

New Book Review: "Lean Integration"

New book review for Lean Integration: An Integration Factory Approach to Business Agility, by John G. Schmidt and David Lyle, Addison-Wesley, 2010, reposted here:

A text published several years ago by the same authors, "Integration Competency Center: An Implementation Methodology", initially captured my interest in this recently released book. Although the authors note in their introduction that this text builds on the earlier work, they also indicate that it is not necessary to read these sequentially. The concept of "lean integation" builds on prior works by other authors such as "Lean Software Development: An Agile Toolkit" by Mary and Tom Poppendieck (see my review), and because of my experience using Agile and Six Sigma, I have continued interest in how I might also apply Lean principles as a consultant. And this interest is especially in light of my involvement in various database and integation related efforts. In the context of this text, the authors broadly define "integration" as "the practice of making independent applications work together as a cohesive system on an ongoing basis", and indicate that solutions typically fall into either process integration or data integration.

This book is divided into three parts. The first provides an overview and justification for Lean as well as an overview of Lean practices and what the authors deem the "Integration Factory". The second part walks through the seven lean integration principles associated with the Integration Factory: focus on the customer and eliminate waste, continuously improve, empower the team, optimize the whole, plan for change, automate processes, and build quality in. The third part discusses best practices grouped by seven competency areas: financial management, integration methodology, metadata management, information architecture, business process management, modeling management, and integration systems. Aside from the typical glossary and terminology that the appendixes provide, the authors also include the "Integration Laws" from the predecessor to this book: "The whole is greater than the sum of its parts", "There is no end state", "There are no universal standards", "Information adapts to meet local needs", and "All details are relevant".

The first two parts of this book continued to capture my interest, and although the third part on implementation practices contains some relevant material, the lack of cohesiveness in these last few chapters was disappointing, and because the term "implementation" used here implies a bit more concreteness than was offered by the authors, my expectations were unfortunately not met. Exceptions include Chapter 11 on financial management, which addresses the ability to secure funding for integration projects, rightly calling this the weakest skills among IT professionals, and Chapter 16 on modeling management, in which the authors address important risks to IT professionals, such as the risk that use of Service-Oriented Architecture (SOA) can lead to new hairballs. As with another recently read book that I recommend, "Enterprise Master Data Management: An SOA Approach to Managing Core Information" published by IBM Press (see my review), one refreshing aspect of this text is that even though the authors are from Informatica, the content remains very much vendor neutral. Well recommended.

New Book Review: "Architecture of Network Systems"

New book review for Architecture of Network Systems, by Dimitrios Serpanos and Tilman Wolf, Morgan Kaufmann, 2011, reposted here:

As the authors explain in the preface, this book was developed for use in university courses at the upper undergraduate and graduate level, using material previously presented by the authors at both the Department of Electrical and Computer Engineering at the University of Patras and the Department of Electrical and Computer Engineering at the University of Massachusetts Amherst. The authors view this text as the first systematic effort to present the architecture of the complete range of network systems as a whole, comprising an overview of network systems architecture, along with discussions on network protocols and network systems requirements, interconnects and switching fabrics, network adapters, bridges and layer 2 switches, routers, transport layer and application layer systems, Quality of Service (QoS), security, specialized hardware components, power issues, networks on chips, run-time support systems, and next-generation internet architecture, as well as an appendix on the layered internet architecture and network protocols.

Having recently managed several virtualization projects for a client, as a consultant I especially appreciated the vendor neutrality, and concise yet comprehensive nature of this text, although the relatively short 300-page length can be a bit deceptive to potential readers not acquainted with academic books in the technology space. In addition, I also appreciated the careful treatment of the authors in their wording, especially that targeted toward unknown audiences. For example, in their discussion of virtualized networks within the chapter on next-generation internet architecture, the authors appropriately state that "this type of virtualization should not be confused with virtualization technology used in local area networks (LANs). Virtual LANs (VLANs) are used to configure logical subnets within a single physical local area network. In such VLANs, the protocol stack is typically the same for all virtual networks. Thus, VLAN technology does not provide as comprehensive a virtualization solution as is necessary for next-generation networks." The multitude of line diagrams provided throughout are always appropriate, and even the appendix has substance. Well recommended.

Liquibase in the Enterprise: Part 4

About a month ago, I completed my second Liquibase project, one of a portfolio of four projects I managed for the client CTO, and an extension to the project first mentioned in my third post in this series. The first Liquibase project that I had completed for another client, although sizeable, paled in comparison to this project.

Now that I have two such projects under my belt, I thought the development community might like to hear about some of the technical lessons learned between these two projects, which were similar in some aspects, but each with its own set of challenges.

While the first Liquibase project involved 6 database instances of DB2 9.5, the second Liquibase project involved 2 database instances of Oracle Database 11g R2. Additional constraints associated with the second project are what complicated matters.

I created 30 schemas associated with 8 application environments across these 2 database instances due in part to Oracle licensing costs, whereas the 6 database instances in the earlier project were each only associated with 1 schema each.

Because database schema names, which are actually users in Oracle, need to be obviously unique within a database instance, the hard-coding (something which I typically frown upon as a consultant architect, although in this case it made sense to do so) to which I was accustomed in the first project was no longer possible.

Initially, it had been requested that I use Apache Ant for the Oracle project, and because of this I had to set up an elaborate series of build scripts that corresponded with a lot of in-line properties due to all the different schema names. Later, I was fortunately able to move to Maven, and automated the entire setup with the profile and filter features that Maven provides.

Although it took time to migrate from Apache Ant to Apache Maven due to experimentation and thorough testing to make sure nothing had broken, I was able to successfully redirect the development team using this project with enough time left prior to my roll-off.

During my presentation of this technology while on the architecture board, I had been asked quite a few questions by the various client sites that had dialed in for my talk. Some questions were centered around Liquibase being an open source rather than commercial product, and one in particular asked whether I had run across any issues with the product.

At the time, I had not run across any issues with the product, but during my Mavenization of the Oracle project I ended up encountering 2 issues during my second round of testing, one with Liquibase 2.0 RC 5 (and presumably Liquibase 2.0.1), and one with Liquibase 2.0.1:

• Reverse engineering an Oracle 11g R2 database schema using Liquibase 2.0 RC 5 does not recognize column defaults of SYSDATE.

Because reverse engineering is typically a one-time process, and is obviously only a concern when a database is not initially created via Liquibase, the likelihood that this will be an issue for readers is probably low.

However, this issue needs to be kept in mind for those deciding to incorporate database change management using Liquibase sometime after initial creation. In my case, awareness that this was an issue did not arise until I tested the Java web application against a new database created with the Oracle project, following a data migration from the corresponding environment database I had also performed.

The simple solution for this issue was to add a series of changeSets to the applicable changeLog, each corresponding to a column in the legacy database which had such a default value defined. For example, adding a default value of SYSDATE to table column USER.CREATED_DATE can be performed as follows:

<addDefaultValue columnName="CREATED_DATE" tableName="USER" defaultValueDate="SYSDATE"/>


This workaround works perfectly, but I needed to fill in the development team why I needed to retroactively insert these changeSets to the project trunk and previous snapshot, especially because it takes some developers getting used to when merging Java code is often done, but in many cases not possible in situations like the one at hand, because Liquibase acts sequentially.

• Creating or updating an Oracle 11g R2 stored procedure or package with Liquibase 2.0.1 is unreliable.

Bundled along with the Oracle project migration from Ant to Maven, I upgraded the JDBC driver to the most recent version, and also upgraded to the latest version of Liquibase, from 2.0 RC 5 to 2.0.1, hoping to move to a "stable" release of the product. While there were no issues with the JDBC driver upgrade, after several arounds of thorough testing there appeared to be no remediation available for the resultant missing segments of PL/SQL, and so I unfortunately settled with Liquibase 2.0 RC 5. This bug was not apparent until I tested the Java web application, because the PL/SQL compiled successfully. It was only after diffs were performed between the code in Subversion and the code in Oracle when the issue was found.

---

Liquibase in the Enterprise: Part 1

Liquibase in the Enterprise: Part 2

Liquibase in the Enterprise: Part 3

Past Book Review (March 1, 2009): "IT Architecture Toolkit"

Past book review (i.e. posted prior to starting this blog) for IT Architecture Toolkit, by Jane A. Carbone, Prentice Hall, 2004, reposted here:

 

Over the past year, this reviewer has spent some time catching up on some of the more recently available texts on enterprise architecture, and quite simply this one by Carbone is one of the best. It is a testimony to the effectiveness of this book that this author is able to bring together in just over 200 pages what other authors are not able to do in two or three times this volume: get to the heart of what enterprise architecture is really all about, provide clear no-nonsense examples of how to reflect the needs of the enterprise in its software systems, and guide the reader along a cumbersome-free step-by-step process that focuses on results.

While Carbone does not view the enterprise as holisticly as T.S. Graves in his recently-penned "Real Enterprise-Architecture" (see my review for that book), this book is much more practical. The author explains in her preface that there were two factors that motivated her to write this book: "the need to plan how data is collected, flows through the organization, and is transformed into information the business can access, is vital" even though there was a time when her opinions and passion about business information "was not always popular", and she has had her "own religious experience...having been honed (some would say charred) on the altar of architecture" and "having learned many lessons the hard way, [she] is anxious to help [the reader] benefit from those lessons".

The "enterprise architecture toolkit" presented here is much simpler than the Zachman Framework, focusing on the upper left-hand rows and provides methods for filling in the cells, and unlike that framework addresses strategies for implementing the target architecture. Carbone is persistent in her communication throughout this book that enterprise architecture is comprised as the business and IT functions working together, unlike some books of this genre which present IT architecture as enterprise architecture, although this reviewer does find it interesting that her "enterprise architecture toolkit" got renamed for the title of the book.

Chapters 2 through 5 focus on the "toolkit business framework" portion of the overall toolkit: the current state of the business and an analysis of that state, and the target state of the business and identification of gaps and opportunities for that state. Chapters 6 through 9 focus on the "toolkit IT framework" portion of the overall toolkit: current and target state architecture, IT inventory, and standards. Chapters 10 through 13 focus on the "toolkit implementation framework" portion of the overall toolkit: projects, metrics, buy-in, compliance, and people.

Essentially, this last aspect of the toolkit places a focus on strategies designed to address and mitigate what the author views as often-repeated mistakes that contribute to solution failure: "attempts to implement too much, too quickly", "inability or lack of willingness to tie implementation to business success", "underestimation of resistance to change", "no commitment and/or buy-in from the entire organization", "lack of supporting enterprise-wide processes", and "insufficient focus on the people issues".

Nine (very lightweight) appendixes, A through I, follow the overall presentation of the toolkit. A recent client of mine indicated very fervently that "the business doesn't know what they need, IT knows what they need"; this book provides an antithesis to that philosophy.

New Book Review: "The Practitioner's Guide to Data Quality Improvement"

New book review for The Practitioner's Guide to Data Quality Improvement, by David Loshin, Morgan Kaufmann, 2010, reposted here:

Some of the other reviews that have been posted here provide some interesting observations from perspectives that are not always centered on data architecture or general enterprise architecture, and the hope of this reviewer is that he will be able to offer feedback to others on this text based on his consulting experience in these areas. In his preface, David Loshin comments that "this book is intended to provide the fundamentals for developing the enterprise data quality program, and is intended to guide both the manager and the practitioner in establishing operational data quality control throughout an organization, with particular focus on the ability to build a business case for instituting a data quality program", "the assessment of levels of data quality maturity", "the guidelines and techniques for evaluating data quality and identifying metrics related to the achievement of business objectives", "the techniques for measuring, reporting, and taking action based on these metrics", and "the policies and processes used in exploiting data quality tools and technologies for data quality improvement".

With these goals in mind, this reviewer thinks Loshin succeeded in this effort. Taking into account the fact that data quality is an enormous practice area, and success requires understanding of both data and the business to succeed, this introductory text walks the reader step-by-step through a considerable number of topics over which many authors would likely stumble. Some of the explanations that Loshin provides, such as the one in the chapter entitled "Developing a Business Case and a Data Quality Road Map" on how data flaws can incur business impacts, are extremely well done, especially when married with effective diagrams. And in his chapter entitled "Metrics and Performance Improvement", the author provides an explanation on drilling through key performance indicators that this reviewer has not seen elsewhere until this effort, and the presentation is exceedingly well done. Other areas of this text that this reviewer especially appreciates are the chapters entitled "Data Requirements Analysis", "Metadata and Data Standards", and "Inspection, Monitoring, Auditing, and Tracking".

This reviewer however would like to make potential readers of this book aware that most of what Loshin provides here is high level walkthroughs and examples of pertinent elements within data quality, rather than practical advice on how to approach much of the lower level work that should be expected to take place on a day-to-day basis. For example, in the chapter entitled "Entity Identity Resolution", the author provides a section on matching algorithms that briefly discusses parsing and standardization, abbreviation expansion, edit distance, phonetic comparison, and n-gramming, which consumes just a few short paragraphs. The author does not explain that there are many more matching algorithms currently in use in industry, that in most cases matching exercises need to take into account multiple rather than single algorithms in isolation, that in the world today internationalization takes an ever more important role when performing matching, and that there is a wide variety of commercial tooling available that needs to be assessed based on the needs of the organization.

However, armed with this knowledge the reader is sure to make use of this work by utilizing it while planning and strategizing data quality, as well as making use of it as introductory material to understanding what it might take to pursue efforts that require a higher level of data quality maturity such as master data management (MDM), in which case this reviewer recommends "Enterprise Master Data Management: An SOA Approach to Managing Core Information" by Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul van Run, and Dan Wolfson (see my review). In the opinion of this reviewer, what Loshin provides here is best suited for managers looking to piece together all of the steps associated with data quality pursuits as well as get a better handle on how each of the steps are interrelated and whether each is a requirement or just an option, possibly looking to solve some aspects of data quality in an evolutionary, piecemeal fashion rather than revolutionary endeavor.

Liquibase in the Enterprise: Part 3

Amazing that it has been nearly a year since I posted Part 1 and Part 2 of my series on Liquibase in the enterprise, and since then these have been two of the most visited posts on this blog. From the data that Google Analytics provides me, it is clear that some visit because they are looking for the proper syntax to use for some operations that I happened to mention in my examples in Part 2. Some are looking for more general information.

But what is becoming increasingly clear is that there is a growing number of individuals who visit because they are looking to see what Liquibase offers, especially when compared to other tooling. For example, they appear to be looking for reviews written by Liquibase users who have been in the trenches so that they can get a better feel for the product, in order to determine whether further investigation is necessary when considering enterprise adoption.

In revisiting what I wrote for Part 2, I think this series started heading in the wrong direction, but I was not initially aware of this because I was knee deep with Liquibase for the first time, and was caught up with some of the detail that can probably be found elsewhere, although write-ups such as this one are extremely rare, and most of the posts I see out there are in regard to Liquibase bugs that development teams have encountered.

While the first client project on which I used Liquibase has ended, I started a new client engagement several months ago where my use of Liquibase has continued. The first project involved a new enterprise database and a team of dozens of software developers, but this new project is a bit different because it involves:

• a specific client application rather than the enterprise
• a legacy database rather than a new database
• hundreds of stored procedures, which we did not permit on the earlier project
• an Oracle 11g database rather than a DB2 9.5 database
• shared database instances between regions, rather than dedicated instances
• a software development team not familiar with agile practices
• a much smaller software development team

However, while these two projects are different, I am noticing a lot of similarities, or patterns:

• initial DBA resistance to Liquibase, followed by acceptance and endorsement
• relatively early approval of Liquibase by management, who see its benefits
• integration at the data storage layer rather than the services layer
• the amount of work involved is easy to underestimate

These differences and similarities can be synthesized into several broad discussion points:

• database purpose
• database product target
• culture: management
• culture: the DBA staff
• culture: the software development team
• work estimation

My involvement on these projects has been as a data architect, enterprise architect, software developer, deployment manager, and project manager. As a consultant, my involvent on projects usually transcends specific roles since I am expected to be able to fill the shoes of multiple individuals in a traditional organization. So in upcoming entries in this series my goal is to explain these discussion points from multiple perspectives. While Liquibase might be viewed as a niche product, and my work with the product involved just a portion of my time on these projects, Liquibase has played a central role throughout.

Speaking of "niche", I realize that this blog is a bit of a niche as well. While as of today Google Analytics tells me that visitors have originated from 90 countries since October, 2009, the number of visitors is in the thousands rather than the millions. And I must admit that the material here can be a bit eccentric, fusing my consulting experience from multiple areas along with reviews of books that I have read to increase my value to clients, together with my occasional thoughts on running, which has been my passion for many years and which contributes to my problem solving abilities for clients.

That said, I look forward to your comments and emails as you visit these pages.

---

Liquibase in the Enterprise: Part 1

Liquibase in the Enterprise: Part 2

Liquibase in the Enterprise: Part 4

New Book Review: "Information Systems Transformation"

Recently posted book review for Information Systems Transformation: Architecture-Driven Modernization Case Studies, by William M. Ulrich and Philip Newcomb, Morgan Kaufmann, 2010, reposted here:

Since the marketplace is largely absent of texts discussing the modernization of software systems architecture, this reviewer did not know what to expect from authors William M. Ulrich and Philip H. Newcomb. In addition, the space of this topic can be very large depending on how it is defined. In the opinion of this reviewer, the best part of what the authors present are the ten case studies, which comprise the bulk of the content, but the initial chapters and concluding chapter provide some initial high-level guidance for managers looking to pursue modernization projects for the first time.

While the case studies presented here offer a variety of scenarios, the potential reader should note that there are some commonalities across these scenarios as well. The tooling and processes utilized across these case studies are shared to a large extent, although there is definitely variation depending on the systems and firms involved. Newcomb is CEO of The Software Revolution, Incorporated (TSRI), and so some of the commonality is due to the tooling and services provided by his firm, for example. The variation provided is largely due to type of system, associated technologies, and modernization approach.

During their initial discussion of challenges facing most enterprises today, the authors note that there is "a lack of understanding by executive teams regarding the impact of these issues and the actions that can be taken to address them for the betterment of the business environment" and that "it is of great concern that software and data assets are largely a mystery to management and planning teams". In following up this discussion with salvaging or rehabilitating legacy systems to provide business value, the authors offer "architecture-driven modernization".

Architecture-driven modernization is defined by the authors as "a collective set of tool-enabled disciplines that facilitate the analysis, refactoring and transformation of existing software assets to support a wide variety of business and IT-driven scenarios". Ulrich later discusses "the four corners of modernization", which consist of modernization scenarios, modernization tasks and disciplines, modernization technologies, and modernization standards, and argues that scenarios form the basis for modernization roadmaps.

Common modernization scenarios include IT portfolio management, replacement/rewrite, COTS package deployment, architecture consolidation, Model-Driven Architecture (MDA) migration, SOA transformation, data architecture migration, user interface refactoring, application improvement, language/source artifact transliteration and platform migration, and data conversion. Ulrich argues that management should be creative and look at a mix-and-match approach that addresses their requirements, and as a consultant who has been a participant in several such endeavors, this review wholeheartedly agrees with this assessment.

As an architect, this reviewer especially enjoyed the following case studies: "Modernization of the Eurocat Air Traffic Management System (EATMS)", "PowerBuilder/4GL Generator Modernization Pilot", and "Veterans Health Administration's VistA MUMPS Modernization Pilot". Note that each of the ten case studies was written by a different set of authors, so the subject concentration and writing style differ greatly between each. Diagram and table effectiveness also varies considerably, and it is no accident that apart from the subject matter of the three case studies sited, these case studies also excel in these areas.

The first of these three spends considerable time discussing all of the steps performed during transformation of Ada 83 code into C++ and Java (the Java solution won). concentrating on performance and duplication of the exact functionality provided in the original system. In contrast to low-level detail, the second of these three concentrates at the high-level, providing a high number of relevant architecture diagrams (to which this reviewer is partial). This reviewer enjoyed the third of these case studies from a business domain perspective, since it concentrates on health care system modernization.

While no book can offer detailed advice specific to the challenges a given potential reader might face in this space, in the opinion of this reviewer the authors offer solid introductory advice on how to start tackling a modernization project, and provide a wide enough variety of case studies that readers can get a feel for what they might encounter in pursuit of such a project. The discussions that the authors provide here definitely delve into the technical, but it is perhaps managers that will benefit the most from a reading of this book, especially the sections that discuss assessments and scenarios and issues underlying traditional approaches such as greenfield replacement and use of COTS software.