Project Governance and Gate Reviews

Thought this may be helpful for those looking at a Governance Process and Gate Reviews for project management. 

This aligns the Capital Planning and Investment Controls (CPIC) process of select, control, and evaluate phases with the Systems Development Life Cycle (SDLC). 

There are 5 notional gate reviews with associated documentation for project conception, initiation, planning, execution, and launch.

Of course, this can be modified as needed based on the project threshold and governance stringency required and seeks to create strategic alignment with the goals of the organization. 

(Credit Graphic: Andy Blumenthal)

Project Governance and Gate Reviews

Birthing An IT System

Managing IT projects is no easy task.

You've got to get the requirements right. 

Technical issues need to be resolved. 

Dependencies have to be lined up. 

Integrations need to work. 

Design should be user-friendly and intuitive. 

Change management takes real leadership. 

And so much more. 

A lot needs to go right for the project to be a success. 

While of course, just one or two bad apples in the project equation can quickly make for a failure if not controlled for. 

But you can't let it...the show must go on, progress is waiting to be made, and the systems need to be delivered for the benefit of the organization. 

This is where real strength and determination by so many good people come in. 

Keep moving things forward--one step at a time--don't stop!!!---another step and another--heave ho, heave, ho--until one day soon a beautiful and efficient IT system is born. ;-)

(Source Photo: Andy Blumenthal)

Birthing An IT System

Who You Calling Ugly Baby?

So in multiple organizations, I have heard systems referred to as ugly babies!

Whether or not it's true, it certainly doesn't make the IT folks that develop, run, and support that system feel very good. 

Are some of these (legacy) systems ugly?

Well, of course, they are. 

Many of them work despite themselves. 

What I mean by that is they are awkward to navigate and use. 

The functionality is flawed or outdated.

The workflows are unnecessarily complex.

The user interface is inconsistent and sloppy. 

The user experience is punishing. 

I told someone recently in using a particular system that was so convoluted:

"Is this system what they give to prisoners and make them use over and over again to punish them for hideous violent crimes?"

Seriously, that's how it felt, even as I knew it was still lightyears ahead of what a paper process still used in other organizations looks like.

Generally better than the waterfall methodology for the systems development life cycle, I understand that one dilemma with agile development is that requirements can be spotty from sprint to sprint and instead of doing the hard work and thinking it out upfront, users are made to expect a nearly endless series of enhancements and tinkering, which isn't practical functionally or financially either.

Even an ugly baby is still ours, and we love it and nurture it, and even help it change for the better--that's part of our responsibility. 

Whether we parented a real baby or an IT system, we have pride of ownership and a sense of accountability to the person, system, and future. 

My father always taught me never to throw out dirty water until you have clean water. 

Similarly, we shouldn't throw out the (ugly) baby with the bathwater. 

We need to work together--technologists and system users--to make truly functional systems and a user experience more like gaming where the players are so happy, attached (and even addicted) to it that they sometimes don't even get up to eat or go to the bathroom. 

We should love what we have and use, and we should, therefore, work hard to make these things great.

And an ugly baby can be made gorgeous again. ;-)

(Source Photo: Andy Blumenthal)

Who You Calling Ugly Baby?

Requirements Management 101

This was a funny Dilbert on Requirements Management. 

In IT, we all know that getting requirements can be like pulling teeth. 

No one either has time or desire to provide them or perhaps they simply don't know what they're really after.

Knowing what you want is a lot harder than just telling someone to automate what I got because it isn't working for me anymore!

In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 

Technology Person: "Tell me what you want to accomplish."

Business Customer: "Tell me what the software can do."

In the end, the customer in exasperation just asks the IT person "Can you design [the software] to tell you my requirements?"

And hence, the age old dilemma of the chicken and egg--which came first with technology, the requirements or the capability--and can't you just provide it!

(Source Comic: Dilbert By Scott Adams)

Requirements Management 101

What Is The Creative Process and Success?

One of my colleagues at work had this hanging on his wall. 

It caught my eye and I thought it was worth sharing.

The creative process (ah, not my style of working, however--I am too much of a planner and worrier): 

1) Work Begins - It starts with, "I have a bright idea" or a "go do" from some other genius. 

2) F*ck Off - Then comes some procrastination and maybe thought process about what you are going to do, but in the meantime, everyone leave me alone to percolate and brew. 

3) Panic - Of sh*t, time is running out, and where the h*ck am I on this project, better get my a*s in gear. 

4) All the work while crying - Hurry, hurry, hurry and get it done. Wa, I feel like such a crybaby and wreck, but I'm going to finish it, I am. 

5) Deadline - Made it by a hair...uh, the whole thing was easy, for me, as pie!

Another thing that I heard this week is that "success is failing to fail."  

Think about that a minute.  ;-)

(Source Photo: here with attribution to Toothpaste for Dinner)

What Is The Creative Process and Success?

Versioning Gone Wild

So software versioning is supposed to be a way to manage change control. 

However, many vendors have gone out of control with versioning. 

1) Incompatibility--It isn't backward compatible, so if you try to work with an older version file/data, you may be sh*t of out of luck getting it to work. 

2) Alphabet-Numerical Soup--We have so many versions of the same/similar thing, we can make your head spin with buyer envy. 

3) Functionally Indistinct--Version changes are so minute or insignificant that there is virtually no difference to the end-user, but you'll love it anyway. 

4) Long And Meaningless--Some versions just seem to go on and on into the weeds...like version 2.10.3.97--ah, let's compare that to the new version of the week of 2.10.3.98, and don't forget the 2.10.4 will be a completely different platform, so you better remember to order the right one. 

5) Upgrade Pathless--You want to be on the current version, well your version is so legacy and ancient, there's no (easy) upgrade path--you have to install 26 patches, hot fixes, and 9 new versions and then you'll be on the right one!

6) Maintaining Multiple Versions--You'll need to maintain multiple versions of the same product, because your data on the older version can't be migrated to the new one. Can anyone say multiple maintenance fees?

7) Out Of Support--Your older version that you spent a lot of money on is no longer current  and is now out of support--so scr*w you unless you pay us again for the next money maker version. 

If you want to kill your brand and possibly your customers' sanity, keep on going mindless version crazy. ;-)

(Source Graphic: Andy Blumenthal)

Versioning Gone Wild

Requirements, I Don't Know

This was a funny cartoon. 

Who are we?  

Clients!

What do we want?

We don't know!

When do we want it?

Now!

This is like way to many IT projects...

The customer knows they need to do something, because of changing market conditions, internal (dys)functioning, arising competition, or external mandates and regulations. 

But when the IT project managers and business analysts interview and ask the customer what they want and need to address these...quite often they get blank faces and hands raised in circuitous, endless doubt. 

What do the customers really want?

For IT to define, solve, and make their problems go away--and by the way do it yesterday and without any extra / proportionate resources. 

For some IT "professionals" that may be a little lacking themselves, you end up getting half-assed solutions to half-baked requirements that accomplish nothing or perhaps even break things more.

Hence, the true miracle of technology--to read minds and deliver valuable solutions to problems that no one could fully define to begin with! ;-)

(Source Cartoon: Roz Blumenthal @Facebook)

Requirements, I Don't Know

A Different Definition For IV&V

In IT circles, IV&V generally refers to Independent Verification and Validation, but for CIOs another important definition for leading is Independent Views and Voices.

Please read my new article on this: here at Government Technology -- hope you enjoy it.

Andy

(Source Photo: here with attribution to Joi)

A Different Definition For IV&V

Flowchart Your Programming

Flowcharts have been used for quite some time for visualizing and organizing business processes and making them more efficient (e.g. business process reengineering).

Now flowcharts are being used to build and link reusable programming code.

NoFlo or Flow-Based Programming (FBP) simplifies application development by using libraries of pre-written code and then dragging and dropping them into your process flows. 

This leverages objected-oriented programming (OOP) and uses modules of open-source code, which are linked together to create a full program that solves a business problem.

The flowchart helps to avoid spaghetti code by providing for a more organized, modular, object-based development environment. 

These flowcharts can not only be a collaborative tool where developers can build or map code, but can also be part of the systems documentation that ensures a higher-level of understanding of the total programming solution. 

NoFlo raised over $100K on Kickstarter in 45 days in order to advance this project from Javascript to iOS, Android, and Python platforms as well. 

To me, this programming paradigm seems to have real legs:
- A process-based model for decomposing solutions
- Simple information visualization through a common flowcharting toolset, and 
- Reusable object code from programming libraries in the cloud. 

I'd say YesFLo--this makes a lot of programming sense. ;-)

Flowchart Your Programming

Is Bureaucracy Just Another Word For Governance?

Fascinating opinion piece by Fisman and Sullivan in the Wall Street Journal on Friday (15 March 2013) called "The Unsung Beauty of Bureaucracy."

The authors argue that bureaucratic rules and regulations serve important purposes in that while "less good stuff gets done--but it also puts a check on the kinds of initiatives that can lead to catastrophe."

And they give numerous examples of industries that perform sensitive functions that you would want to actually take some extra time to make sure they get it right.

A vary basic example given was the company Graco that makes infant car seat and strollers; they have five design phases and hundreds of tests that add up to two years to product development, but who would rationally argue against such quality controls processes to protect our children.

They make another good point, we always here about bureaucracy slowing the innovation and product development down, but what about the "bad ideas that were quashed as a result of the same rules?"

We all rail against having to jump through hoops to get things done and rightfully so. The mission is important, time is of the essence, and resources are limited--last thing anyone wants is to be told you have x process that must be followed, y gates to get through, z signatures to obtain--and that's just for the routine stuff! :-)

But as much as we hate to be slowed down to cross the t's and dot the i's, often that's just what we really need--to make sure we don't do anything half-a*sed, stupid, or jut plain reckless.

One mistake in an operational environment can bring things to a standstill for thousands, in a system it can have a dominos effect taking down others, and in product development it can bring deadly consequences to consumers, and so on. 

So putting up some "bureaucratic" hurdles that ensure good governance may be well worth its weight in gold. 

Frankly, I don't like the word bureaucracy because to me it means senseless rules and regulations, but good governance is not that.

We need to stop and think about what we are doing--sometimes even long and hard and this is difficult in a fast-paced market--but like a race car taking the turn too fast that ends up in a fiery heap--stopped not by their steady pacing, but by the retaining wall protecting the crowds from their folly.

One other thing the author state that I liked was their pointing out the government which is involved in so many life and death matters needs to maintain some heightened-level of governance (I'll use my word), to get the food supplies safe and the terrorists out.

From clear requirements to careful test plans, we need to ensure we know what we are doing and that it will work. 

At the same time, showing up after the party is over serves no purpose.

Like all things in an adult world, balance is critical to achieving anything real. ;-)

(Source Photo: Andy Blumenthal)

Is Bureaucracy Just Another Word For Governance?

SDLC On Target

I found this great white paper by PM Solutions (2003) called "Selecting a Software Development Life Cycle (SDLC) Methodology."

The paper describes and nicely diagrams out the various SDLC frameworks:

- Waterfall
- Incremental
- Iterative
- Spiral
- RAD
- Agile

It also provides a chart of the advantages and disadvantages of each framework. 

Finally, there is a simple decision cube (D3) based on time horizon, budget, and functionality for selecting an SDLC framework. 

This is a very useful and practical analysis for implementing SDLC, and it aligns closely with the guidance from the National Institute of Science and Technology (NIST) Special Publication (SP) 800-64, "Security Considerations in the Systems Development Life Cycle" Appendix E that states:

"The expected size and complexity of the system, the development schedule, and the anticipated length of a system's life may affect the choice of which SDLC model to use."

While NIST focuses on the time horizon and complexity versus the PM Solutions Decision Cube that uses time horizon, budget, and functionality, the notion of tailoring SDLC to the project is both consistent and valuable. 

Just one more resource that I found particularly good is the Department of Labor IT Project Management guidance (2002)--it is a best practice from the Federal CIO website.

I like how it integrates SDLC, IT Project Management, IT Capital Planning and Investment Control (CPIC), and security and privacy into a cohesive guide. 

It also establishes project "thresholds" to differentiate larger or more significant projects with greater impact from others and calls these out for "more intensive review."

Even though these these resources are around a decade old, to me they are classic (in a good sense) and remain relevant and useful to developing systems that are on target.

(Source Photo: Andy Blumenthal)

SDLC On Target

Platforms - Open or Closed

Ever since the battles of Windows versus Linux, there have been two strong competing philosophies on systems architecture.

Many have touted the benefits of open architecture--where system specifications are open to the public to view and to update.  

Open sourced systems provide for the power of crowdsourcing to innovate, add-on, and make the systems better as well as provides less vendor lock-in and lower costs.  

Open Source -----> Innovation, Choice, and Cost-Savings

While Microsoft--with it's Windows and Office products--was long the poster child for closed or proprietary systems and has a history of success with these, they have also come to be viewed, as TechRepublic (July 2011) points out as having an "evil, monopolistic nature."

However, with Apple's rise to the position of the World's most valuable company, closed solutions have made a strong philosophical comeback.

Apple has a closed architecture, where they develop and strictly control the entire ecosystem of their products. 

Closed systems provides for a planned, predictable, and quality-controlled architecture, where the the whole ecosystem--hardware, software and customer experience can be taken into account and controlled in a structured way.  

Closed Systems -----> Planning, Integration, and Quality Control

However, even though has a closed solutions architecture for it's products, Apple does open up development of the Apps to other developers (for use on the iPhone and iPad). This enables Apple to partner with others and win mind share, but still they can retain control of what ends-up getting approved for sale at the App Store. 
I think what Apple has done particularly well then is to balance the use of open and closed systems--by controlling their products and making them great, but also opening up to others to build Apps--now numbering over 500,000--that can leverage their high-performance products.

Additionally, the variety and number of free and 99 cent apps for example, show that even closed systems, by opening up parts of their vertical model to partners, can achieve cost-savings to their customers. 

In short, Apple has found that "sweet spot"--of a hybrid closed-open architecture--where they can design and build quality and highly desirable products, but at the same time, be partners with the larger development community. 

Apple builds a solid and magnificent foundation with their "iProducts," but then they let customers customize them with everything from the "skins" or cases on the outside to the Apps that run on them on the inside. 

Closed-Open Systems -----> Planned, Integrated, and Quality PLUS Innovation, Choice, and Cost-Savings

Closed-Open Systems represent a powerful third model for companies to choose from in developing products, and which benefits include those from both open and closed systems.

Platforms - Open or Closed

Staying Open to Open Source

I don’t know about you, but I have always been a pretty big believer that you get what you pay for.

That is until everything Internet came along and upended the payment model with so many freebies including news and information, email and productivity tools, social networking, videos, games, and so much more.

So when it comes to something like open source (“free”) software, is this something to really take seriously for enterprise use?

According to a cover story in ComputerWorld, 10 May 2010, called “Hidden Snags In Open Source” 61% say “open source has become more acceptable in enterprises over the past few years.” And 80% cited cost-savings as the driving factor or “No. 1 benefit of open-source software.”

However, many companies do not want to take the risk of relying on community support and so “opt to purchase a license for the software rather than using the free-of-charge community version…to get access to the vendor’s support team or to extra features and extensions to the core software, such as management tools.”

To some degree then, the license costs negates open source from being a complete freebie to the enterprise (even if it is cheaper than buying commercial software).

The other major benefit called out from open source is its flexibility—you’ve got the source code and can modify as you like—you can “take a standard install and rip out the guts and do all kinds of weird stuff and make it fit the environment.”

The article notes a word of caution on using open source from Gartner analyst Mark Driver: “The key to minimizing the potential downside and minimizing the upside is governance. Without that you’re shooting in the dark.”

I think that really hits the target on this issue, because to take open source code and make that work in a organization, you have got to have mature processes (such as governance and system development life cycle, SDLC) in place for working with that code, modifying it, and ensuring that it meets the enterprise requirements, integrates well, tests out, complies with security, privacy and other policies, and can be adequately supported over its useful life.

If you can’t do all that, then the open source software savings ultimately won’t pan out and you really will have gotten what you paid for.

In short, open source is fine, but make sure you’ve got good governance and strong SDLC processes; otherwise you may find that the cowboys have taken over the Wild West.

Staying Open to Open Source

Comments from OMB's Chief Architect: Kshemendra Paul

Recently, Kshemendra Paul, Chief Enterprise Architect, at the President's Office of Management and Budget (OMB) made the following critical comments to me about business cases and pilots and incorporating these in the Systems Development Life Cycle:

"I was online and came across your site -
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.

I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don't do it well - meaning that we don't force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).

Also, this is a step that is inevitably cross boundary - either on the mission side and for sure on the funding side.

Second, I'd like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan."

I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.

Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a "paper" (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.

Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.

It's great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.

Secondly, as to Kshemendra's point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It's a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.

Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)

With both business cases and pilots for new IT projects, it's a clear case of "look before you leap." This is good business and good IT!

Comments from OMB's Chief Architect: Kshemendra Paul

Frameworks and Enterprise Architecture

One of the issues facing IT professionals these days isn’t a scarcity of IT frameworks, but rather many good frameworks that can be in conflict if we do not sort them out.

Usually each framework is focused on a certain lifecycle, which on one hand helps align it to a certain view on things, but on the other hand complicates things further, because each framework attempts to be all things to all people, by covering an entire lifecycle.

Here are some examples of the frameworks and their associated lifecycles:

• Enterprise architecture – the IT investment life cycle (Capital Planning and Investment Control, CPIC)
• SDLC—the Systems Development Life Cycle
• ITIL –the service lifecycle
• PMBOK—the project lifecycle
• CMMi—the process lifecycle
• Configuration Management—the asset lifecycle

Each framework has plans that need to be developed, processes to be followed, reviews that get conducted, and go/no-go decisions issued.

If an organization attempts to introduce and utilize all these frameworks then there can result a major overlap of structures, processes, and reviews that can literally drive a project manager or program sponsor nuts!

The organization could grind to a standstill trying to comply with all these frameworks.

I believe that each framework has useful information and guidance for the organization to follow and that the key to implementing these is to determine which is the PRIMARY framework at various stages of IT. The other frameworks may overlap in the stages, but it is the primary framework that guides that each stage.

Here’s an example using a few of these:

1. Enterprise architecture is the decision making framework for IT systems. It has a core function in influencing IT investment decisions based on the target architecture and transition plan and EA reviews of proposed new IT projects, products, and standards. Therefore, EA is the primary or dominant framework in the planning stage of IT (up to the IT investment decision).
2. SDLC is the development framework for IT systems. SDLC has a core function is guiding the software development process. As such, SDLC is the primary framework for the development phase of the system (which comes after the IT investment decision and before operations and maintenance). Of course, SDLC has planning phases and O&M and disposition phases as well, but SDLC is the primary framework only in the development stage.
3. ITIL is the service framework. It has a core function in determining how service will be delivered and supported. ITIL is the primary framework for the O&M stage of the system (this comes after the development and before the disposition of the system), since that is when the system needs service delivery and support. Again, ITIL has other stages that overlap with other frameworks, for example planning and configuration management, but ITIL is the dominant framework only in the O&M phase.

The other frameworks should conceptually also assume a primary role for specific phases of IT and then pass off that role to the next framework that is dominant in that particular area.

4. For example, maybe PMBOK would have a dominant framework role also in the planning phase, looking at cost, schedule, performance, resources, risks, and so on (this would be after the IT investment decision of EA and before the development or acquisition phases). Again that is not to say that PMBOK doesn’t shed light and provide requirements for other stages of IT—it does—but it just is not the primary framework for those other stages.

I believe it is only by developing a unified lifecycle and assigning primary framework “ownership” to each stage will we be able to develop a truly workable IT structure and process for our organizations. As the saying goes: ”Two kings cannot sit on one throne.” So too, two frameworks cannot be simultaneously guiding our project managers and program sponsors nor taking up valuable IT resources.

The end goal is a single, simple, step-by-step process for our projects to follow with clear actions, milestones, and reviews, rather than a web of confusion and siloed, redundant governance processes in play.

Frameworks and Enterprise Architecture

Portfolio Management and Enterprise Architecture

Enterprise architecture and portfolio management are closely linked activities. EA drives IT investment management (including the IT portfolio select, control, and evaluate phases) by conducting technical reviews of proposed new IT projects, products, and standards, and IT investment management provides important information updates to the EA (baseline, target, and transition plan).

In Architecture and Governance Magazine, Issue 3 Volume 2, Nuttall and Houghton provide an overall framework that goes “Beyond Portfolio Management to Comprehensive Application Governance.”

The framework includes three main areas and one supporting process area, as follows:

1. Application and License Management (tactical)—“It manages the demand side and user requests, the contract and compliance aspects of determining the number of licenses that are contractually allowed, along with the projects that bring new products into the portfolio while retiring older products that have been removed. In many ITIL organizations, a help desk/service desk would handle the demand for applications, while the license management aspects are often assigned to the procurement and/or configuration management functions.”
2. Application Portfolio Management (strategic)—“determines the appropriate mix of applications in the portfolio. It s highly dependent on the strategic business drivers for the corporation and includes: portfolio strategy development, optimization, and planning.” Portfolio strategy development determines the drivers and priority of those. Portfolio optimization determines the right mix of applications to support those goals. And portfolio planning determines the risks and constraints in implementing the portfolio, such as architecture, infrastructure, and resource constraints.
3. Financial Management—“budget and forecasting, account management, and allocations management;” these enable the planning of what money is available for the portfolio and what money is spent for applications.
4. Supporting Processes—other process areas that impact portfolio management include: “knowledge management, communications management, management reporting, architecture strategy, risk management, operational delivery, and support management.”

“One thing is certain, though, as technology continues to drive productivity, comprehension of application governance will become an even more essential step for companies wishing to manage their risks and costs while continuing to gain strategic value from their portfolios.”

I think this model is very helpful in decomposing the traditional definition of governance from the strategic functions of portfolio selection, control, and evaluation to the additional tactical, strategic, and financial aspects involved in managing it. Particularly, I believe it is useful to separate out the business demand (licenses, new systems and technologies) from the portfolio development and optimization (“the right mix” to satisfy user needs). Additionally, the breakout of financial management from the portfolio development is important in making the distinction between the roles of the Investment Review Board/Enterprise Architecture Board and the financial or resources group that actually budget and accounts for the funding aspect of IT spend.

Nuttall and Houghton do not go into any depth with the supporting processes, so these are presented as high level touch points or supporting processes without any particular explanation of how they support portfolio management and governance.

One critical item, the authors did not include, but should have included is the Systems Development Life Cycle, which take the IT portfolio and governs it from planning through analysis, design, development, testing, deployment, operations and maintenance, and ultimately to disposition. The success of moving systems projects through the SDLC will impact the make-up of future portfolio decisions.

Portfolio Management and Enterprise Architecture

Do-It-Yourself (DIY) Application Development and Enterprise Architecture

The Wall Street Journal, 24 September 2007 reports that “new [DIY] tools let businesspeople avoid the IT department and create their own computer applications…and no knowledge of computer code is required.”

How does this benefit users?

• “Users say they are saving time and money by creating their own applications”
• They “are able to build exactly what they want, without having to explain what their looking for to someone else.”
• “Others like being able to wite programs that would have been too minor or personalized to bother the IT department with.”
• “Adjusting DIY programs…can also be simpler than asking the IT department for program tweaks or updates.”

What are the downsides?

• “There is some risk in the lack of a track recod for such companies [offering these DIY services], and in the possibility that a provider will fail, leaving its customers without access to the applications they developed online.”
• “Some businesspeople may underestimate the effort required to write their own programs.”

Strangely enough, the article leaves out some of the biggest gaps with DIY application development, such as:

• Approval by the organization’s IT governance to ensure that the ‘right’ projects are authorized, prioritized, funded and monitored for cost, schedule, and performance.
• Compliance with an organization’s enterprise architecture to ensure such things as: business alignment, application interoperability and non-redundancy, technology standardization, information sharing, and strategic alignment to the target architecture and transition plan.
• Assuring IT security of applications systems, including confidentiality, integrity, availability, and privacy.
• Following a defined, repeatable, and measurable structured systems development life cycle (SDLC) approach to application development.

The WSJ article actually compares DIY application development to when businesspeople learned to create their own PowerPoints presentation rather than having to run to the graphics departments to build these for them.

While there may be a place for DIY application development for small user apps (similar to creating their own databases and presentations), from a User-centric EA perspective, we must be careful not to hurt the enterprise, in our efforts to empower the end-users. A balanced and thoughful approach is called for to meet user requirements (cost effectively and quickly), but at the same time protect enterprise assets, meet strategic goals, and assure overall governance of IT investments.

Do-It-Yourself (DIY) Application Development and Enterprise Architecture

SDLC, CPIC, PMBOK, and EA

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC	CPIC	EA	PMBOK
Conceptual Planning	Select	Business Alignment	Initiating
Planning & Requirements	Control	Technical Alignment	Planning
Design			Executing
Development & Testing
Implementation
Operations & Maintenance	Evaluate	Architecture Assessment
Disposition			Closing

The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

• Select—How does the investment meet business decision criteria?
• Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
• Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

• Business Alignment—Does the investment support the agency mission?
• Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
• Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

• Initiating—Define and authorize the project.
• Planning—Define objectives and plan course of action.
• Executing—Integrates resources to carry out project management plan.
• Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.

SDLC, CPIC, PMBOK, and EA