As an infrastructure architect who was recently tasked with evaluating the changes required to support an enterprise mobility program, I can tell you that the hardest part is deciding where to start. The main question I needed to address was, What is the difference between an existing IT infrastructure without mobility and an infrastructure that is required to support mobility?
Mobility in the enterprise has become a pervasive trend that is causing IT infrastructure professionals to rethink the ability of their existing IT infrastructure to support an enterprise mobility strategy.
One critical point to keep in mind when integrating mobility is the threshold point where any additional workload may overburden the existing infrastructure. Another factor to consider is the additional requirements of mobile application software lifecycle activities that rely heavily on the compute, storage and network domains.
In my experience, an architectural block model can greatly help me to internalize the respective domains in a more structured way for architectural thinking. A diagram like the one in Figure 1, which represents a high-level perspective of the infrastructure, can help you to initially assess which areas may require change.
On the organizational side, the architecture model also allows various stakeholders to understand where they function in a mobility roadmap. It should be noted that this model can be modified for additional domains, and each domain could be expanded as required.
Figure 1: An overall mobility strategy encompasses multiple domains of an IT infrastructure.
The advantages that I found of using this model are as follows:
- Identifying where products and services fit into the overall IT infrastructure architecture
- Assigning or negotiating ownership for the management of the domains
- Adjacencies between domains and integration requirements and understanding the interdomain dependencies
- Understanding the impact and risks of change within a specific domain
This architectural model can also be a precursor toward consideration of a mobility roadmap that outlines short, medium or long-term activities based on criticality and funding.
Corresponding to the model from Figure 1, Figure 2 shows how the discrete mobility components can then be associated within the respective domains. The advantage I found in using this thought process is seeing where and how the addition of an entity would fit in the overall infrastructure.
Here is a brief description of the domains shown in Figure 2:
- IT service management: The people, process and technologies that need to be aligned to support and manage the mobile users
- Security: Governs a corporation’s security policies associated with mobility within the enterprise space
- Governance: Regulates a corporation’s compliance and audit policies on mobile usage
- Mobile application platform: Software for the development and implementation of business-to-employee (B2E) and business-to-consumer (B2C) applications, including application management
- The server and storage (compute) domains for virtualized application support on mobile devices
- The network transport layer for the wide area network (WAN) and the local area network (LAN) components to support mobility connections
I have used this model both internally and externally with clients. Though it may seem basic, it has helped me start a conversation about IT infrastructure optimization. It also helps us to assess prospective mobile technologies and their insertion points in the overall infrastructure model. As the adage goes: “A picture paints a thousand words.” (Of course acronyms help too.)
Do you think this model could help businesses to implement a mobile strategy within their existing IT infrastructure? I’m interested in the applicability and limitations of this layered view, and I’d love to hear your feedback on how this could fit into the enterprise mobility landscape.
Connect with me on Twitter @TonyPYLiew.