TOGAF & Application Downsizing

Context

Based on one of my past missions, a short story about how business side may see IT side and how TOGAF envision may help about that. Let’s name my customer Company.

Company has launched a program to reduce IT operational costs and move toward open standards. One key step is to downsize a huge core business application from z/OS to Linux. I conducted a short consultancy mission to help Company to elaborate downsizing scenarios encompassing short-term and mid-term goals.

Example of short term goal: get rid of z/OS as soon as possible.
Example of mid-term goal: operate open source technologies.

TOGAF ADM vs downsizing case study

A first question is: does TOGAF Architecture Development Method (ADM) apply to such a case? My short answer is: Yes.

Even if the subject sounds clearly surrounded by IT only matters, one can at least use TOGAF as a guide to position the problem in a wider IS transformation path. And also expose through the ADM the global bounds for the “elaborate scenarios” mission:

TOGAF for application downsizing

­

Furthermore, in a “TOGAF applied to TOGAF” style (see TOGAF 9.1 part VII), one may probably imagine a closer match between the downsizing question and the 4 Architecture matters of TOGAF:

• Business = IT requirements for target architecture related to consequences for IT people and IT processes
• Data = application assets (source code, application parameters, etc.) and execution infrastructure assets (OS, monitoring tools, etc.). And not “application data” as data will not change at all, notably in this case as they already have been downsized
• Application = the new Application Life-cycle Management tools and processes, the new processes for operating living applications
• Technology = target technologies = new programming languages, new application life-cycle tools, new OS and tools

If one may imagine this mapping, it’s rather hard to sell it as a study methodology !

TOGAF for not business relative cases

While writing this post, I realized that the way I leaded the study followed roughly this TOGAF ADM pattern.

The main, and key, benefit having been to be able to get an explicit expression of all key points and fears from Company’s key IT people about the downsizing process and target. And also to make appearing some nuances in the application parts that lead to imagine differentiated trajectories for several groups of components.

However, the point in this post is: does this iso-business iso-functional downsizing process has, or should have, impact to “real” business?

One answer is: the target specification must, at least, not introduce negative IT capabilities considering the business roadmap.
I therefore asked the business roadmap question to IT representatives: “What does business people say or want about this application?”.

Business concerns at last

I got three answers:

• Requirement 1: Some business managers would like to have a commercial package instead of a home made application
• Requirement 2: All business managers would like to reduce the cost and time needed to train new salespersons
• Requirement 3: Some business managers would like to have a better time to market response time when new kinds of product arise on the market as competitors are usually faster than Company

May downsizing helps about theses “high level business requirements”?

Commercial package

Requirement 1 is obviously… Not a requirement!

It is maybe a solution to some true requirements like cost reduction, better time to market, etc. But it should not be accepted as a business requirement by itself.

Training costs

Requirement 2 is a true requirement. The application has a B2C channel where customers may buy products through a web portal. Even a new customer, used to surf on the internet, will achieve this in a matter of minutes. So, it seems hard to understand that Company salespersons need a several weeks training to do the same operations.

Same? Really? Not sure. There are probably here complex or specific sets of commands that need more complex processes than what can be achieved trough a B2C web portal. And based on sales statistics, one can probably imagine to have several kinds of salespersons, with separate training sessions.

Whatever, this requirement should lead to consider a new “transformation” project focused on sales business processes and new ergonomics for the Point Of Sale.

How does this is related to the downsizing step? Obviously, the downsizing target must enforce the SOA principles already adopted in the Company, and also give a high priority to target technologies that allow a very good flexibility for the GUI part. But the “new POS” is definitively a separate project. If only due to the huge work t do with business users about their expectations.

Time to market

Requirement 3 seems to be a true requirement… but it’s complicated!

Short version: Company differentiates from its competitors – among other points – by a specific way to package its products to address its customers needs and wishes. This specificity has benefits but also costs.

The added value put into the way products are packaged also means that it costs much time to imagine the way to package a new product and to implement this new specification. So, in terms of pure response time to market Company is usually slower than competitors.

But after double thinking this is not the same offer! So, the main point here is not necessarily to improve an IT capability but probably rather to revise or strengthen the business model itself. And to do that before considering IT implementation!

TOGAF is about Architecture

In conclusion, but still to be proven with more than just some single cases, I guess TOGAF may help conducting architecture downsizing projects. On both sides: organizing the way to address IT needs and helping to sort direct and indirect business needs.

Both sides are faces of the very Enterprise Architecture.