Are You Global or International?

Is your organization global or international? Do you know the difference? Does it matter in terms of how you plan for and carry out technology operations such as support, procurement, hosting or messaging? You should know and yes, it makes a huge difference to the structure of your technology operations. Trying to operate a global technology strategy at a company who is truly an international entity will surely pit business needs against your technology goals, setting the stage for failure. So are you global or international? I am sure there are volumes of business school literature on this topic but here is a simplified distinction that is immediately relevant to your technology planning efforts.

Global companies will produce standard products or services that are not tailored to the specific tastes or needs of specific country markets. Usually, such products or services will not be differentiated by brand recognition and may represent either commodities that serve as inputs to other products or services or as standard outputs that don’t vary across markets. An example could be an organization who produces chemicals that go into other industrial products to produce a final result. While certain aspects such as specific packaging or regulatory considerations may vary from market to market, there is more commonality across markets than differences. This has a huge impact on how you are able to design and structure your technology systems and associated services. There will likely be a single set of business systems that have been slightly customized to fit the needs of specific markets. A centralized infrastructure and associated support model may function well in a global organization. Such centralized services could potentially go beyond commoditized IT services such as email hosting to include more advanced services such as centralized Service Desks. Can all technology services be centralized in a global organization? Of course not, local market needs will always dictate some degree of local flexibility. In a global organization however, the technology synergies across operations in different regions around the world will outweigh the need for local differentiation.

International companies may operate in markets around the globe, but tend to offer distinct products or services in each market that are customized to local tastes or market requirements. Products or services such as consumer goods that rely heavily on brand recognition tend to be heavily tailored to local tastes, customs and trends. For example, a packaged meat company operating in Asia, Europe, Latin America and the US will likely have highly differentiated SKU’s for each specific market. In addition to product differentiation, consumer goods often have very distinct and varying methods of distribution across global markets. For example, in the US, consumer goods may be delivered to central warehouses of large big box retailers who then ship products through their own logistics chains to grocery shelves. In some Asia markets, the dominance of the small, local shops may dictate a Direct Store Delivery (DSD) model where product is delivered straight from the manufacturer to the store shelf. In International organizations, the need for local market flexibility will dictate a need for market specific technology services. This does not mean there are no technology synergies to be had at international organizations. Again, commodity services such as email hosting or centralized infrastructure support along with leveraging buying power through centralized procurement may represent true opportunities for working globally while acting locally.

I have obviously painted this topic with a wide brush but hopefully the point is clear. Understand the needs of your organization in terms of its operations around the world. Don’t try to centralize services where local flexibility is needed in order to win in the local market. Don’t leave services local that represent cost saving or opportunities for scale when managed centrally. Understand that there are times when being global and being international are not the same and that a misaligned technology strategy can hamper your organizations success in either case.

Get Rid of Custom Scripts to Reduce Risk and Improve Scalability

What are the advantages and disadvantages of custom scripts in your daily technology operations? It seems at first thought that using custom scripts for daily tasks such as database backups or ftp transmissions is a great way to keep down costs. Why pay for a product such as NetApp's Snap Manager for SAP when at first glance all it does is put the database in hot backup mode and then leverage SAP tools such as brbackup to execute the backup? The true "techie" baulks at paying for "fancy push buttons" when a good old shell script can accomplish the same thing. As a technology manager however you need to consider what the true costs and risks of custom scripts in your daily technology operations actually are. I make the argument here that the fewer custom scripts you have in your environment the better off you are.


Let me be clear on what I mean here by "custom script". I am referring to either UNIX shell scripts or Windows VBScript and PowerShell scripts. Let me also be clear on what I mean by "daily operations". Here I am referring to repetitive tasks that happen everyday in your environment such as database backups and file transfers. I am not referring to one time administrative bulk operations such as Active Directory maintenance for example.


Custom scripting introduces risk by building dependencies on the knowledge of the individual who creates the script.

We all know that we should have solid backups for individuals on our technology teams. In large organizations with hundreds of technology workers it is common to be two or three deep on every position. That is not the world most of us live in however. In the typical midsize organization with a 20 something head count in IT there is generally one or two "super stars" that have the technical horse power to automate daily operations with custom scripts. The more you allow these custom scripts to permeate your daily operations the more risk you bare should one of your super stars leave. Off the shelf products for daily operations counteract that risk in two ways. First, they ensure that through the use of best practice configurations and maintenance contracts that you have an 800 number you can call and expect support. With a large vendor’s support organization behind you, you should be able to sleep easier at night. Second, through the use of GUI interfaces and the publication of best practice documentation, you make it more likely that more of your technical staff, not just your superstars, will have a solid understanding of how systems are backed up, files are transferred etc.. The key concept here is transparency. It should be clear to everyone how things get done on a daily basis.


Custom scripting makes auditability of daily operations much more difficult.

Many technology managers today are feeling the pains of compliance with such rigorous audit and security standards such as SOX and PCI. Rarely will custom scripts be able to provide the robust set of operational reporting necessary for regulatory compliance. Auditors will also have certain packages that they are familiar with. Auditors will have specific things they are looking for relative to the most popular security and backup software vendors. Presenting auditors with a plethora of custom scripting and reporting that doesn’t "fit" their model will likely not bode well. I once had a technology manager tell me that auditors are some of the most unimaginative people he had ever meet. There is some real truth in that sentiment.


Custom scripts are not as scalable as off the shelf applications.

Even if you have a stable group of IT superstars, after a while custom scripts begin to get out of hand. After a certain amount of enterprise growth, it becomes difficult to manage the interconnected web that custom scripts can weave. Custom scripts may also not be capable of handling the sheer volume enterprise growth may bring to your organization. So, while custom scripts may seem cheaper in the short-term, their long term scalability should be called into question.

In summary, while true blood techies often espouse the benefits of custom scripts in daily operations, as a technology manager you should be aware of their true impact on your enterprise. Keep in mind the risks and scalability issues you may encounter by leveraging custom scripting versus standard products. Be aware that the true "fully loaded cost" of custom scripts may be higher than what you will pay for standard packaged software.