Study notes on Cobit: Determining technological direction

The need for enterprise wide standardized technologies

Suppose that you're the CIO of a company and have decided to acquire an ERP system and a CRM system to support the business strategies of optimizing the supply chain and enhancing the relationship with the customers. You've assigned two architects to work on those two projects respectively. If they don't communicate and you don't coordinate their decisions, it is possible that they will adopt completely different technologies that they consider the most suitable, like:

• ERP: Linux server, Windows XP clients, DB2 database, web-based, Java.


• CRM: Windows server, Windows 7 clients, Oracle database, client-server, .NET.

If they are allowed to go ahead like that, you'll be in big trouble:

• Your infrastructure team will have to manage both Windows and Linux servers and thus have to learn both and deal with the quirks of both.


• Your DBA will have to manage both Oracle and DB2 and thus have to learn both and deal with the quirks of both.


• Your PCs just won't be able to access the two systems at the same time! Some PCs will be used to access the ERP system, while some others will the CRM system.


• It is difficult for the two systems to share information (as mentioned in "defining information architecture") as they don't support the same database management system.


• If, say, you're already using Oracle, introducing DB2 into the environment may create uncertainty and instabilities.


• If you need to customize the two systems, you will have to find both Java programmers and .NET programmers.

Therefore, you (the CIO) should have a process to coordinate the technologies used by different applications as proposed by the architects. For example, you might standardize all new projects on:

• Linux server


• Oracle database


• Java


• web-based


• Windows 7

Then you'll be able to leverage the same people (system administrators, DBAs, programmers) and the same resources (Linux server, Windows 7 clients) for both applications, enjoying economy of scale and better interoperability (e.g., now possible to share information).

What about legacy technologies?

For example, you may have an existing accounting system written in Cobol running in AS/400 accessed through a terminal. This is certainly holding you back in economy of scale and interoperability. Therefore, you should consider working out a plan to migrate the legacy technologies to your selected standardized technologies, after considering the benefits, costs and risks.

Looking forward and updating your standardized technologies

Of course, you can't stick to your standardized technologies for very long; Windows 8 may be released in a couple of years, cloud computing may take off, there might be legal regulations for cloud providers to ensure the security for customers, credit card security standard might change (PCI DSS), mobile phones may become the primary computing client, SOX might be updated and etc. So, you need to keep monitoring for new technological trends, legal, social or economical trends that may have technological impacts, and then create a future set of standardized technologies for your company (thus establishing a technological direction) and a plan for migration.