The New IT Leader

Underlying Risk of Enterprise Mobility

The propagation of smart phones and introduction of solid state devices such as the iPad, coupled with increased bandwidth in LTE networks, mobile computing is becoming a fact of life that IT organizations are going to have to grapple with.  As with many of the technologies that are consumer driven, the integration of these mobile devices often start at the C Suite of a company and quickly proliferate into the rank and file. Consider the ever growing extension of the enterprise into a consumer driven market is a nightmare for risk managers trying to protect a company’s intellectual capital and systems infrastructure. 

Unarguably these devices provide a means for businesses to be more productive and agile, and are a temptation that cannot be avoided.  They also blend work and personal business on a level never before experienced by technology organizations as many of these devices are owned by the employees rather than the company (although that trend is starting to change as some companies are adopting tablet computers as a new standard for portal computing devices rather than deploying laptops).

Being that many of these devices are employee owned, companies also now have to deal with the ramifications of having personal devices access corporate assets.  This introduces an unprecedented level of risk, HR, and legal issues that companies have never have had to deal with before. 

This trend is only going to continue as the computing platform paradigm shifts from computing at a desk to computing available to you wherever you are and whatever you are doing.  In so much that these technologies are being adapted (and thriving in the consumer market), companies need to understand the risks involved with extension of their enterprises beyond the virtual walls of their networks and what to do to mitigate those risks. 

Key risks and mitigation strategies include:

Information Security

Access to e-mail and company contacts area major reason for having a mobile device.  However, there is the ability to use these devices for checking personal e-mail as well as connecting to social media sites (e.g. Facebook, Twitter, Digg, etc.).  Whereas many companies have established policies to protect their laptops from these types of vulnerabilities, mobile devices will also need a similar protective framework.

Mitigation Strategy:

• Mobile policy management – if users are going to use their personal devices to access corporate information, then policy enforcement on those devices is a must (such as  multi-factor authentication, device password lockdown, and data wiping capabilities, etc.).  There are several choices available in the market to help manage these policies to secure information on mobile devices
• Education – ensure that there is mandatory education required for any employee that is using their mobile device to access corporate assets so they understand and acknowledge the risks and their responsibilities for using those devices

Location Sensitive Information

One of the great capabilities of mobile devices is to interact with social media sites and allow them to know your location automatically so you don’t have to provide that information whenever you post to these sites.  However, for companies (especially companies that keep employee locations secret), this is an exposure that needs to be addressed.  Take an armored car service as an example.  If you have an employee who is posting to their Facebook during while working, it would not take long for someone to piece together the patterns of where that employee has been on particular days and map out their regular routes, potentially exposing the employee and the company to theft or other crimes.

Mitigation Strategies:

Education and awareness – like Information Security, education is critical; but awareness of what information employees are posting to social networking sites is also critical.  They need to understand the implications of providing location information especially when they are on the job

Disable location capabilities – on managed mobile devices, push the policy to disable this feature.  For those devices that are not under corporate management, educate employees on the importance of disabling this feature to protect the company and more importantly, the employee

Audits – for highly secure delivery services, regular audits of employee online activities may be necessary to ensure compliance to these policies.  This is a very sensitive issue and should be carefully reviewed by your legal and HR team before implementing

Vulnerabilities from unsecure devices and networks

Given that many of these devices are personal devices, they will likely be synced with home computers or other computers not directly under the security umbrella established by your company.  Further, these devices can connect to open wireless networks such as hotels and coffee shop networks, making them potentially vulnerable to access from others. 

Mitigation Strategies:

Policy enforcement – if the device is being used for accessing corporate information, policies should be pushed to the mobile devices to govern how users get access to corporate information through these networks

Mobile security software – there are multiple vendors available to protect the cell phones from a variety of threats including antivirus, anti-spam, and activity logging

Education – once again, education is a must.  Have users understand the risks of attaching to unsecure networks and be sure they are aware and note any unusual activity while they are connected to those networks

Connectivity into corporate wireless networks

Personal devices connecting into corporate networks expose companies to a variety of risks of unmanaged devices.  Risks include introducing viruses or trojans into the corporate computing environment or unauthorized access to information assets.    

Mitigation Strategies:

Policy enforcement – for devices that have both Wi-Fi and 3G/4G wireless connectivity, ensure that they can only connect to one network at time to ensure no external network tethering can take place

Unauthorized Devices Management – ensure that your wireless network only allows whitelisted devices to connect to your internal network or have the ability to detect new devices connecting to the network.

Education – corporate policies should be in place and communicated to employees to prevent unauthorized devices to connect to the corporate network

Measuring Data Center Efficiency

The services that you provide the business is dependent upon having a well-run data center.  The reason being is that a big part of your value proposition to the business is minimizing the overhead costs in the delivery structure.  For data centers, this means maintaining it as efficiently as possible.  These efficiencies include power, cooling, density, data throughput, and storage.  Whether the data center is owned by your company, or you co-locate with a service provider, or if you use the cloud, those costs are factored into the investment that the business has made in technology.  The costs are unavoidable, but it is how you manage those costs that will drive whether you are value add to the business or not. 

I’ve included some metrics that I’ve used over the years to measure data center efficiency.  There is much debate over which metrics should be used, especially what is presented to the business.  My advice is to look at your organization and determine which ones make more sense for you in how you deliver services to the business (for example, you will have less visibility into these metrics for a co-located solution than you would if your organization managed the data center itself).  That being said, the business does not (usually) want to see all of these metrics.  What they want to understand is that the costs are being managed ably and how those costs translate into the services being provided. 

 I’ve broken down data center efficiency metrics into these categories:

• Hardware – metrics addressing how efficient is the hardware in the data center.  This includes all server, storage, and network in the data center.  Hardware innovations and virtualization have attributed to the improvement of server efficiency.  As solid state begins to move in as a way of providing storage, those metrics will continue to improve as well. 
• Power – this is the most expensive commodity used in a data center.  Data center managers need to understand how much power is consumed, and where it was utilized.
• Personnel Requirements – measurements of how much automation has been introduced into the data center by way of how many people are needed to support and manage the data center
• Systems Management – describes the performance of the data center from an application or service point of view

One note on these metrics – when I discuss square footage, I am referring to the data center floor only (not the periphery offices that flank the data center). 

Hardware

Hardware metrics describes how much computing power can be provided given a certain amount of space.  Server, storage and network are evaluated when discussing hardware metrics.  Better utilization means lower overall costs for the data center.

• Data center density – the number of CPUs cycles (not CPUs) per square foot of data center space.  The more cycles a CPU can perform in a given time period, the better the ratio. 
• Storage density – amount of storage per square foot of data center space.  This is the sum of all storage, allocated and not allocated.        
• Storage utilization – how much of that storage is allocated to systems (whether they are using it or not).  There has been much written and debated about this metric.  My perspective has been that if the business is paying for it and it is allocated to them (regardless of whether it is actually used or not) it is unavailable for other to use, and therefore should be calculated as part of the utilization. 
• Network utilization – how much bandwidth is available in the data center and how much of it is being used.  Multiple embedded metrics included are network capacity, saturation, and availability.

Power and Heat

Power and heat have an interdependent relationship with each other.  You need power to run the data center, but that comes at a cost in the way of heat generated, which then drives cooling costs.  Also, as data center density has improved, so has increased heat generation. 

• Power efficiency – CPU cycles vs kW-h to support the data center.  That involves all costs to support the data center including storage, network, HVAC, etc.  If you have high density data center, this metric will improve.  This can go beyond just CPU cycles and encompass storage (terabytes per kW-h) and network (throughput per kW-h)
• Heat efficiency – BTUs generated against CPU cycles.  The equipment will generate heat and you have to cool that by way of power.  The more heat generated, the more it costs to supply the power.  If you have the ability to within your data center, you can extend these metrics to include storage (terabytes per BTU) and network (throughput per BTU). 
• Power Usage Effectiveness (PUE) – total power provided to the facility over the power requirements of the technology equipment
• Data Center infrastructure Efficiency (DCiE) – the power requirements of the technology equipment over the total power provided to the facility

Personnel Metrics

These metrics measure how much automation you have within the data center.  Of course the lower the count the better, but these metrics help you understand within your peer groups how efficiently you manage your data center.  Keep in mind that people in the data center contribute to degraded HVAC performance, so the fewer people you have in the data center, the better. 

• Number of employees / contractors per square foot.  It is critical that you capture all personnel resources directly responsible for the management of the data center.
• Number of employees / contracts per CPU cycle.  Another view into the management of your data center by way of CPU cycles.  I prefer to use square foot as a measure as it reflects more of the physical limitations that you are working with and it is more universally used. 
• For larger data centers, you will want to break these metrics down into these areas
  • Server and server density  
  • Storage and storage density
  • Network and network utilization
  • Facilities management by way of either of power or BTU

Systems Management

These metrics cover the services that are provided from the data center to the application teams and ultimately the business.  While I can’t say these metrics could be classified as pure “efficiency” metrics, they provide the end results of the services delivered from the data center and are important checks against the efficiencies in the data center. 

• Availability – from a data center perspective, this is a measure of the services that are available to the applications or services running inside the data center.  I have used this number as an aggregate of all of the technologies and facilities required to make a server or service available.   
• Capacity – again, from a data center perspective, how much capacity is available to the services that are being provided.  This is usually discussed as physical capacity and virtual capacity, network, storage, HVAC, and physical space. 

Other Metrics

The metrics discussed in this article deal with operational efficiency of the data center.  There are many more metrics involved in planning and managing a data center that should be considered including, emergency preparations, security controls, safety and fire controls, monitoring statistics, quality assurance, server / network / storage / software costs, performance, cooling, and layout efficiency.

Do you really know your applications?

The business owners that I’ve worked with have expressed to me that one of the most frustrating experiences they’ve had with IT organizations is extended systems outages.  The impacts to their operations are as wide reaching as the scope of the business processes they support. Some of the more notable impacts to the business included:

• Financial penalties for missing critical milestones
• Overtime paid to operations staff to catch up on the backlog of work
• Revenue impact resulting from loss of customers
• Costs associated with acquiring or reacquiring customers   
• Impact to customer and production analytics resulting from data loss, especially around high-volume transactional systems

More than likely, the cause behind extending the outage was the lack of unremarkable documentation about the application, system, or service that would allow the IT department to speed service restoration. 

The question here is do you know enough about your applications to restore service quickly if for some reason they take an outage?  In my experience consulting and working with various applications and infrastructure teams, the answer is no - chiefly amongst applications or infrastructure that have been transferred from one manager or team to another.    

Source code and requirements documentation is not sufficient.  The nature of systems and services developed now go beyond older constructs of client / server environments and instead are developed on a framework of interdependent services such as cloud computing.  So to understand these systems require a larger documentation framework.  It should include information about the services, their dependencies, information about the server and network infrastructure, and their respective SLAs.

I have used this framework to document the various systems that I’ve had to support.  This framework should be used in conjunction with coding and requirements documentation to provide a holistic view of the applications / services your team is required to support:

• Overview – a section describing the purpose of the application or service and impact to the business.  Include here key contact information and usage (such as who is using the services)
• Key supporting tasks – a description of the tasks that are required to support the application or service and who performs those tasks
• Maintenance tasks – what are the regularly reoccurring tasks that must be performed and who performs those tasks
• Server information – what are the servers, VMs, SAN, or other devices that are used to deliver the services or applications you support
• Backup schedule – when are the backups made for each of the devices that are mentioned in the previous section and what type of backups are made.  You also want to know the recovery SLA for each backup.
• Reboot / maintenance schedule – if there is a regular reboot schedule for any of these devices, or other maintenance windows that would require an outage of these dependent devices, you will note them here as this will play into your SLA calculations
• Databases – the name, location, and configurations of any databases that are used and any security requirements or configurations associated with these databases
• Architecture diagram – a diagram of how the various technical components fit together.  Include any dependent services that your application or service depends on.  Also include the network infrastructure and any specific security requirements inherit to the network infrastructure
• Services – list out the names of the services that the application or service physically runs and any permission requirements that are needed to support those services.  Also list specific child processes that are implemented that either may be implemented on their own or as a part of another service and their purpose in delivering the application or service.
• Key files and configurations – list any files that are used in support of the service or application.  If this is a Wintel environment, note any registry entries that are required as well
• Recovery procedures – layout the disaster recovery procedures that are in place (or reference their location) as well as any procedures to recover parts of the system, particularly those components that may be prone to corruption or failure. 

As you can see, the documentation of a system goes far beyond the narrow confines of source code and requirements document.  If you have this as a minimum, your ability to recover from an outage will improve.  This is also not an inclusive list.  You may find the need to document other infrastructure or configurations such as firewall rules or other security protocols needed to support your application or service.  The goal here is to have as much information about the systems you maintain as possible.

Saying that, if the system is poorly documented and / or inherited, this will not be an easy task to complete.  It will take some time, but the benefits to the busienss of going through this exercise clearly outweigh the time investment that you will make in working through this. 

A Quick Note on the Enterprise Architecture Organization

In the minds of CIOs that I have met with, Architecture is a critical function within their IT organization.  I don’t believe there is any debate of the intrinsic value of an architecture team.  They set the technical and process framework that a technology organization will work in.  This ranges from the security standards, to server and network infrastructure standards, and application frameworks that the company will leverage, and business process integration standards.

In an environment where information is readily available all the time, it is critical that the architecture function of a technology department establishes a workable structure for technologist to follow to provide that information to customers and employees.  As an example, the birth of social networking has established new channels for companies to reach out to its customers.  First the first time, as a collective, customers are interacting with each other and companies in real time.  If they have not already done so, companies need to look at how to reach out to their customer base in this new medium.  Architecture teams play a major role in providing the plan to tap into this customer channel.

While it is relatively easy to establish these standards, the trick is to put that framework into the correct context for operational and project use.   With the need to set an overall direction for IT and the need for practical application of that vision, the question that comes up is how you manage an architecture team.   The implementation of an architecture function is as varied as the organizations they serve.  I’ve found though that there are two distinct services that architecture functions need to provide: strategic vision and tactical application of that vision. 

Strategic

The strategic function drives those decisions about leveraging which technology to support the business need and the technology direction that should be used.  This includes the validation of existing and new infrastructure and application requirements.  For argument sake, let’s call these folks “Enterprise Architects”.  The Enterprise Architect needs to develop strong relationships with the business lines that the technology department serves, as well as solution vendors in the development of standards.  They also drive the integration of those standards into the PMO by way of process integration and assuring that there is accountability within the project gates as well as operational functions.

Tactical

The tactical side then provides the context.  Within each project or operational issue that comes up, there is always the challenge of determining how to apply those architecture standards to any given situation.  This is where the tactics of applying the standards set come into place.  Quite frankly, having the various technical team police these themselves is not very effective.  In these cases, you will often find decisions that were made that are not in the best interest of the bigger vision for the company, costing both time and money.  Depending on the scope of the project or operational issue being addressed, the expense can be quite large and from an accountability perspective, unforgiving.   

Again, for argument sake, let’s call these folks that make tactical decisions” Solutions Architects”.  Their role is to put the architectural standards into practical application.  They need to be working with the various technical teams to advocate and enforce the use of the standards set for technology. 

Organization

Organizationally, Enterprise Architects need to be an independent function.  The application of Solution Architects is handled in a variety of ways from being imbedded in each of the technical teams with dotted line responsibility to Enterprise Architecture, or provided as a pool of resources assigned to each technical team, but reporting directly into the architecture organization. 

The actual implementation will work in either scenario, but the key here is to develop a structure whereby the architecture standards can be enforced and audited.