In-Depth
How Total Architects Enable Project Success (Part 1 of 4)
Introducing the "Total Architect" and the benefits this position can bring to your enterprise.
By Frank Bucalo, Enterprise Architect, CA Technologies
Throughout my career, I've read claims that as many as 75 percent of IT projects end in failure. This number has remained consistent over the life of IT regardless of the target platform: mainframe, PC, client-server, and now service-oriented architecture (SOA). In the face of this tragedy, I've come to know a group of colleagues who have reputations as being able to deliver successful projects with almost a 100 percent success rate. It often perplexed me as to why we were able to succeed where others had failed.
I wasn't aware of a name to describe us or any corporate consciousness that there were individuals with a unique set of skills that could increase IT performance while reducing costs. That was until I came across Dr. Paul Brown's works; he coined and defined the phrase "Total Architecture." His premise is that people, processes, information, and systems are too complex and intertwined to deal with them in a disjointed manner.
This article will use four real-world project scenarios to illustrate that a "Total Architect" is an asset you cannot live without.
A project typically consists of a highly-skilled team with specific skills. For example, the project might have a business stakeholder, often with advanced degrees and many years of specific business experience. It also might have a business analyst (BA). For the sake of our composite project, let's assume that our BA has an MBA and many years of experience.
The team might also have a number of developers, both local and overseas, with top-class credentials. Furthermore, it might have several architects with specialties such as security, database, network, and Web design. All of these people come and go on the project as their skills are required. Finally, the team could have a project manager, who possesses a Project Management Professional (PMP) certification and, again, many years experience.
The question becomes, "How can a project with such an assemblage of qualified and seasoned professionals fail?" The answer is that, unlike other types of projects (such as road construction) where an assembly-line approach makes perfect sense, IT projects evolve throughout the project life cycle. The project management body of knowledge (PMBoK) refers to this as "progressive elaboration."
During this progressive elaboration, everything shifts, requiring a broad set of skills to be continually engaged. Otherwise, there will be long and slow communication loops, breakdowns in communication, and unnecessary rework; project failure is likely. Rather than using a large team with specific skills, a smaller team with multiple skills (including a Total Architect) can prove to be effective and efficient.
Failure Scenario #1: People
The business stakeholder meets with the BA and together they produce a detailed set of specifications. The architects then define various aspects of the system, and the developers create the system. After many months, the system is unveiled and the business stakeholder says, "No, that's not it."
The problem here is that business stakeholders, being abstract beings, rarely concretely know what they need, what their business rules are, and what trade-offs they might have to make to balance project cost, quality, and time constraints. A Total Architect can help: a Total Architect knows various project approaches, including their strengths and weaknesses.
The approach above -- called the waterfall methodology -- rarely produces successful business-oriented projects. Instead, an agile methodology is preferred. That method engages the business stakeholder (or a designated representative) along with the Total Architect, to progressively elaborate the requirements using a rapid application modeling tool. Such a tool makes the abstract requirements concrete, allowing the business stakeholders to see the implications of their requests; adjustments can be made quickly and inexpensively in real-time.
Failure Scenario #2: Process
After weeks of analysis, the business analyst presents the development team with a process flow. It consists of four boxes -- labeled Step 1, Step 2, Step 3, and Step 4 -- with arrows between them. The developers, based offshore, are expected to code the process quickly and inexpensively. However, there are a couple of problems here that often result in project failure.
The first is the process has not been sufficiently vetted. That is, the Total Architect knows that in addition to the steps involved in a process, other factors must be defined. Such factors include:
- The data elements
- Failure scenarios (what happens if this step cannot be completed?)
- Concrete process actors (specifically who or what performs this step, and how do I get and maintain that list?)
- Security requirements (does this information need to be encrypted across the wire or in the database?)
- Levels of service (is this step time sensitive?)
- Transaction volume
Based on knowledge and experience, the Total Architect drives requirements and defines such factors at a sufficient level.
The second problem is many current workflow tools are graphically driven with code only being required for special processing. For example, I've known workflow tools to include database actors, form actors, and other components that are configured but require no code. Consequently, by the time sufficient details have been locally defined and configured, there is almost no work to be sent to offshore resources. This isn't a problem by itself, but it is problematic if project projections underestimate the effort of process definition and overestimate the coding effort.
Failure Scenario #3: Information
The business stakeholder works with the developer using an agile methodology. Together, they produce an application that functions well for one year. When the next fiscal year starts, however, they realize that the data architecture does not support multiple fiscal years. Redesign and redevelopment are required.
This type of project failure is particularly insidious because the failure isn't recognized for a year -- long after the "project success" celebration dinner.
The problem is that although an agile methodology is useful for driving business requirements, it often overlooks architectural issues. The Total Architect knows there is a need to ask probing questions to drive out data requirements. In this case, a simple question (Do you want to track things over time?) would have driven out the missed data requirement and avoided the project failure.
Failure Scenario #4: Technology
The business analysis requirements have been defined and the application rapidly built using an agile methodology. Now the messaging infrastructure architect enters the picture. He notifies the business stakeholder that the system will not scale to thousands of messages per second and that the messages are too big for the infrastructure to handle. He concludes that the project must be scrapped and a new solution, that will take a year to develop, must be defined.
A Total Architect knows that based on time, quality, and cost constraints, an application that is "good enough" is often the right solution. In this case, the largest number of messages per second ever required by this application was numbered in tens, not the thousands the messaging architect assumes.
In addition, a Total Architect is aware of the capabilities and limitations of the technology used by the solution. For example, having reviewed the documentation for enterprise messaging tool, the Total Architect noticed that it is possible to configure the tool to "chunk" messages so that large messages can be sent in pieces, thereby resolving the presumed message size issue without the need for mass firings or expensive redevelopment.
The Final Word
Given the deep expertise, broad knowledge, and experience that a Total Architect provides, such an individual would seem to be expensive. However, when you consider that they fill multiple roles simultaneously, reduce the number of staff resources required on a project, and decrease project failures and the associated sunk costs, they actually prove to be cost effective.
Frank Bucalo is an enterprise architect with CA Technologies specializing in ITIL implementation and risk management systems. Prior to his time at CA Technologies, he was an architect and a consultant with banking and brokerage clients. He is a member of the Global Association of Risk Professionals (GARP) and an ITIL Service Manager. Mr. Bucalo represents the new breed of "Total Architect" – knowledgeable and experienced across business, technology, and technology management domains. You can contact the author at frank.bucalo@ca.com.
- - -
Other articles in this series:
Part 2: Traits of a Total Architect ... And All That Jazz
Part 3: Hiring a Total Architect
Part 4: Putting a Total Architect to Work: Lean IT Implementation on Steroids