Top Most The Business of IT - ROI and CBA

Two common tools businesses use to aid decision making are Return on Investment (ROI) and Cost Benefit Analysis (CBA). Use these tools to help sell your ideas to your management.

ROI is used when "spending money to save money". The analysis is simple and the result is a period of time, often expressed in months.

Simply start with the amount you spend, add up your savings over time, and see when they net out. That will be your ROI. Everything after the ROI is savings, so the analysis typically presents a few years into the future to highlight how much money you'll be ahead (and how clever you are).

Depending on your management, a simple analysis may be close enough, or they may want a more thorough analysis that includes the time-value of money (i.e. the investment income you'll lose by spending it), tax ramifications and other costs expressed as "present value".

In that case, delegate to that staffer who whines when they do not get promoted each and every review.

Cost Benefit Analysis (CBA) is when you weigh expected costs versus expected benefits of one or more options to choose the best one. Both costs and benefits are expressed in money and may be a simple calculation or may include the time value of money expressed as "present value".

With a CBA benefits need not be restricted to typical expense and revenue concerns such as staff reduction. CBA's can include myriad benefits such as market presence, public relations, recruiting, industry and financial analysts, community contributions, carbon footprint, green initiatives, etc. etc.

Here it pays to include all realistic benefits.

Any business analysis must be compelling to be useful, and must be clearly communicated to be compelling. Back up your analysis with industry accepted measures and you'll earn a reputation for "doing your homework" before presenting to management.

Cheers

Top Most Architecture in the Enterprise

Recently I heard about a consulting company that sent a prospect to interview for an Enterprise Architect role. The interviewer, resume in hand, zeroed in on the lack of EA experience. Unfortunately the folks who set this up never identified this as an Enterprise Architect role. The prospect was a software architect, not an Enterprise Architect.

Unfortunately some managers in recent years have appropriated the term 'architect' after running out of titles for the senior developers. Senior-senior developer? Master developer? Guru developer? I must admit, 'architect' sounds better.

In reality architecture is a set of disciplines, each unique and specific. Beware of the unmodified term "architect", it has no meaning without context.

In my experience, I have seen the following architecture roles:

Enterprise Architect
Enterprise architecture is performed at the strategic level. Typically EA's plan future-state architectures for the enterprise. They do no development at all and actual development experience is helpful but not necessary. EA's can provide competitive advantage over the long run. They can also bring an enterprise to it's knees.

Technical (or Solution) Architect
This is a project-level position that recommends the hardware best suited for an application or system of applications. Actual development experience is helpful but not necessary.


Chief Architect
In the mid-late 1990's architects were seen as overhead, but motivation existed for CIO's to have an architect. This would be a very senior person, essentially the only named architect in the enterprise. Nowadays Chief Architect is sometimes used to designate the top architect, or can be just a ceremonial title.


Application Architect
Works at the project level, typically overseeing all technical aspects of the project. This is the original "architect", responsible for frameworks and design, aka "software architecture". Typically promoted from Technical Lead, the best AA's have been know to improve developer productivity by 2 times or more.

Network, Security, Data, Infrastructure, etc. Architects
These are technology-specific professionals who create enterprise standards, assist development teams and provide governance. They are responsible for their specific technical space, ensuring it meets project and enterprise requirements.

Summary
Each architecture role aligns with Enterprise Architecture and strategic business initiatives. For example, years before the current services trend, good application architects would design to support services, since future state architectures were likely to move to a Services Orientated Architecture.

Each architecture role is fairly specific with little overlap. They are specialists who help tame the complexity required of enterprise solutions through standards, governance and best practices. Some can play multiple roles with training and experience, but they are generally not interchangeable.