Evergreen IT refers to running services comprised of components that are always up to date. Evergreen IT encompasses not only the services at the user level, but all of the underlying infrastructure, whether onsite or outsourced. Many organizations believe that evergreen IT holds promise for reducing the resources and energy they need to expend on providing the up-to-date and flexible services that their users are demanding.
This article, based on the experience and observations of Microsoft Enterprise Architects, explores the nature of evergreen IT and what it requires of IT systems, as well as the challenges that IT organizations face in pursuing the most common types of evergreen IT solutions.
The following contributors provided input: Johan Klut, Larry Hanthorn, Mary Lynn Pontier, Peter Deane, Robbi Laurenson, Sree Sundaram, and Stephen Kell.
Companies like the idea of offering applications that are always up-to-date or that can change quickly in response to business needs. Companies also seek to provide this flexibility while reducing the time and expense required to do so.
However, most companies find these goals next to impossible to reach using their current systems, technology, and management approaches. As systems have become increasingly complex, the amount of effort and expense needed to maintain them has increased, and the prospect of making changes to them has become daunting. Businesses may have to change their IT strategies and infrastructure to pursue evergreen IT.
For IT organizations that want to keep all of their systems in-house, converting to evergreen IT is similar to modernizing their data centers:
Many companies aren't interested in an extensive overhaul of their IT systems. As a more economical solution, many companies conclude that the best way to control the burden of updates and restore flexibility to their systems is to replace some of them with cloud-based evergreen services.
However, simply subscribing to an evergreen service does not make an IT organization evergreen. In order to get the full value out of an evergreen service, the IT organization still needs to modify its systems and strategies to become at least partly evergreen itself. Integrating with an evergreen service impacts at least the following areas:
Subscribing to an evergreen service is only one step toward providing users with an evergreen experience. The IT organization needs to make sure that its applications and their supporting infrastructure are compatible with the service, and—most importantly—that it can maintain that compatibility as the provider updates the service.
For example, some companies have published APIs to facilitate business-to-business integration with both their suppliers and customers. Their IT organizations now have to think of themselves as service providers, and provide versioning support and backward compatibility for the API customers. These IT organizations need to be sure that an updating service won't disrupt these APIs.
Smaller companies typically find it easier to adapt their IT organizations and technology to evergreen IT. For example, multiple standardized but configurable systems are easier to update than multiple custom one-off systems. But standardizing systems is easier to accomplish for smaller organizations than for larger organizations that may be burdened by accumulated legacy systems.
The IT organization's operations and management processes need to account for and respond to factors that originate outside the company—outside of the traditional IT domain. These impacts can affect many different areas of operations and management, some obvious and some less so. Issues that the IT organization may need to deal with include:
How should the change management processes accommodate the evergreen service?
An IT organization that is mature enough to successfully integrate an outsourced service typically uses a change management system to log all change proposals and approvals for the managed systems. However, an evergreen service provider is unlikely to send its frequent updates through each customer's change management process. The IT organization needs to confirm what kind of communications or notifications the provider can supply.
How should the incident management processes accommodate the evergreen service?
If there is an interruption in service, incident management processes need to trigger immediate remedial action as well as appropriate communication between the business and the service provider to help resolve the issue. Microsoft, for example, is helping businesses using Office 365 to adjust their incident management processes.
What privacy and data security standards must be applied to this service?
In a general sense, using a cloud-based evergreen service means treating the internet as part of the business network and the business network as part of the internet. The IT organization must ensure that the data processed, communicated, or stored by the service is appropriately protected. In addition, the IT organization must ensure that integrating the service into its systems does not introduce vulnerabilities or possible avenues of attack.
How does the company's regulatory environment affect the way it can use the service?
Regulations may restrict how a business can use a cloud-based service. For example, some countries require that companies store certain types of data onsite, and not in the cloud. In other cases, regulations may restrict the ways in which the IT organization can integrate the service into its systems.
How do budgets need to shift to accommodate the evergreen service?
Typically, subscribing to an evergreen service reduces a company’s capital spending on IT, while increasing its operational (service) spending. Depending on the magnitude of the service costs involved, such a change may take a full budget cycle to implement. In addition, implementing the service may incur substantial one-time costs for training, communication, and change management. In the long term, the business may have to adjust its budget cycle to accommodate the evergreen service billing schedule.
Does the IT organization's Help desk need to support the evergreen service, or does the service provider include support?
What legal issues may arise from using the service?
Although the IT organization may not need to maintain as many systems as before, it needs to keep the remaining systems coordinated with a constantly changing evergreen service.
To do this, the IT organization needs to improve its agility and efficiency. Many companies have built their IT organizations around the need to design, build, and run large-scale services—projects that can span years. Adapting to an environment where services may update every few weeks or months—with updated content under the control of an external provider—can be challenging, especially for large IT organizations.
The IT organization needs to maintain a close relationship with the business units and other customers it supports. As the evergreen service changes, the IT organization needs to communicate any potential disruptions to the business units, and provide information about new or changed features. In addition, the IT organization needs to understand the needs of the business units and make sure that the service is meeting those needs.
IT organizations can pursue evergreen IT as a means to improve the level of service to the business while controlling costs. To get the full value out of evergreen IT, the IT organization needs to do more than just subscribe to a cloud-based evergreen service: Effectively using that service may mean changing existing systems, revising management processes, and changing the way the IT organization interacts with the business it serves.
Delivery Documentaries are a behind the scenes look at how our Enterprise Architects (EAs) in the field perform Value Realization activities for customers. The documentaries are raw and real, and the purpose is to share what actually happens on the ground. They are always a learning opportunity, and we hope that over time we can help bridge the state of the art with the state of the practice, and continue to move the ball forward.
What happens when a business that is struggling with a problematic project brings in a Microsoft Architect to help create a recovery plan? Let’s see…
This is a Delivery Documentary of an engagement led by the Microsoft Enterprise Strategy Program (ESP), which provides services to help customers realize the most value from their technology investments. In this engagement, the Enterprise Architect led a team in diagnosing issues with a problematic project and recommending a recovery plan.
This project involved assessing and correcting the course of an existing project: developing a customer relationship management (CRM) system using agile methodology. As the deliverable for this engagement, the sponsors requested a new roadmap for the project that accounted for the current organizational goals.
I reviewed the available information on the project to date, including the engagement proposal, the existing project roadmap, and the previous status presentations and other presentations about the engagement’s history and issues.
We held the first meeting with the executive stakeholders to define the engagement and set expectations. To address problems arising from a lack of communication during the initial project, we recommended that we create a governance board to receive weekly status reports on the engagement. The stakeholders agreed, and the board consisted of the following members:
I explained that we would gather data about the project by holding workshops with the employees that would be using the CRM system at the agency headquarters and in each of the affected divisions. I asked the business stakeholders to recommend participants for the workshops, including representatives of the IT group that would be supporting and managing the system. To ensure that everybody involved had the same understanding of the workshops, I requested that all participants attend a single kickoff meeting.
I gathered the resources I would need from both Microsoft and the business. We brought in a Microsoft CRM expert to act as a SME with regard to the project itself. The company provided a resource to help schedule meetings and workshops, and a SME who was familiar with both the business and the technology of the organization.
The team would provide insights into daily operations, as well as the applications and infrastructure that employees used. In addition, the team also reviewed the models of business and technology processes, and provided feedback.
We conducted workshops separately for the headquarters of the organization, and for each division that the CRM system affected.
At the workshops, we collected information from employees, including:
We asked participants to assign ranks and weights to these goals. We could then prioritize the problems and features based on the goals they impacted.
We analyzed the data for each business division, as well as across all divisions. The rank and weight assignments provided raw data for statistical analysis. We used methods such as standard deviation to refine cases where participants in a single group provided ranges of rankings instead of consistent rankings. We also examined dependencies, patterns, agreements, and disagreements both within and across divisions.
The various divisions did have some common goals and initiatives, but they also had markedly different priorities. For example, some employees saw no value in the CRM system because the features that had been implemented so far were not useful to them.
Some groups had conflicting priorities: For example, in one division, employees who answered phone requests from customers were rewarded for keeping the calls as brief as possible; as a result, they collected minimal information from the customers, and often neglected to collect and record the information needed by other divisions.
Other factors in the analysis included, for example, observations that communication issues between the divisions were a recurring problem, and the processes that the CRM system was supposed to support were not well documented. We also noted mistakes that had been made over the course of the project.
We identified themes that would impact the final roadmap. Updating the roadmap itself was primarily the work of the CRM SME. In addition to the roadmap itself, we prepared general recommendations for improving the structure and governance of the project, and for improving the relationships between the parties involved.
As part of these recommendations, we emphasized that the business continue using the governance board that was established for this project, and expand the board to include both field representatives and representatives of stakeholders higher in the organization.
The stakeholders accepted the updated roadmap and recommendations that we presented, and agreed to resume the project with our help.
The following actions on our part were key to forming a great relationship with the business and becoming trusted advisors to the stakeholders:
In general, this engagement demonstrated that:
What happens when a company considers strategies for enabling future business transformation by focusing on the business organization as a whole, rather than just the IT organization and practices? Let’s see…
This is a Delivery Documentary of an engagement led by the Microsoft Enterprise Strategy Program (ESP), which provides services to help customers realize the most value from their technology investments. In this engagement, an Enterprise Architect helped the company examine possible strategies for its future approach to business transformation with information and technology.
Rather than focusing on a particular IT solution, this engagement was more about integrating technology into business strategy. As such, the analyses addressed the business organization as a whole instead of just the IT organization and practices.
A consultant for the company connected me to an executive within the business. The executive was interested in a holistic analysis of problems facing the business (and the industry as a whole).
The consultant and I researched the industry. We found that in the domain of the company’s business, the following issues are currently affecting production, and those affects are increasing:
Defining the Scope and Assembling a Team
The consultant and I discussed some possible approaches to help solve challenges around meeting resource demands. We considered analyzing the business processes and overhauling them according to “Lean” methodology, but we decided that this approach would take too long. We considered treating the issue as a knowledge management problem or a workflow improvement problem, but both approaches were too small in scope to address the problem effectively.
We finally decided to target our analysis on all of the processes associated with obtaining resources, and by examining the value chain. We planned to gain a holistic view of these processes, taking the following factors into account:
Our goal in this analysis was to produce a roadmap that Contoso can use over time to create the technology, functionality, and information that to support the needed business capability. Contoso already had implemented a number of solutions for providing workers with information they needed to do their jobs; however, these solutions did not share information and workers had to access multiple applications during tasks. A holistic approach would be more efficient.
We planned to center our analysis on models of the business, generating and revising those models based on meetings with workers involved in core processes. We wanted to develop models that would be sophisticated enough to simulate the business processes and operations. We would then be able to:
At this point, the following additional resources joined the team:
The team members helped write the vision document for the next phase of work. They also planned out the workshops that we needed to hold with the staff.
We met with business leaders at the company to explain our approach, which would use information gathered from the workers themselves to model the current business environment and processes. Based on these models, we would be able to recommend changes that would help close the capability gap through leveraging the appropriate technology.
To gather the information, we held a series of workshops that were designed based on our previous experiences with such engagements.
Our goals for the workshops were to:
The workshops themselves focused on learning about the workers: who they were, what they did, why and how they did it, and who they worked with. We asked for their goals and the problems that they commonly dealt with, separating personal and business issues.
We also asked them to rank these issues. We approached these sessions from both the user experience and business architecture points of view. Our user experience and business architecture experts helped refine and facilitate the workshops so that both areas could be addressed in a single, continuous session.
We worked with Contoso staff to create preliminary models based on industry research, benchmarks, knowledge management and search theory, and so forth. We were able to start expanding and revising the models as we obtained specific information from the workers themselves.
We applied statistical techniques to the ranked goals and problems; the results provided insight into priorities. We also defined a taxonomy that the team could use to describe the data and results.
In general, we looked for patterns in the workers’ responses, issues and priorities that were common to both the junior and senior workers, and areas in which the groups differed. We noted the impacts of the worker’s environments, perspectives, and variations in data handling.
We modeled Contoso’s organizational maturity with respect to its workers, business, knowledge, and the ways in which information was used and distributed. This model was particularly important for Contoso because the business processes were not written down, but instead were embedded in the organizational culture.
Using this information, we produced an agent-based process model for engineering processes using personas and meaningful scenarios. Contoso outlined the scenarios of interest.
Finally, we identified a set of themes based on the workshop data, defined changes that Contoso could make that would yield measureable benefits, and mapped dependencies and relationships among those benefits. We mapped the themes and benefits into a model focused on capability.
We presented our results and recommendations to several different sets of stakeholders, from engineers to executives. We adapted our presentations to the audience. Where appropriate, we used formats that the company used internally.
We organized our findings into three deliverables:
Welcome to the Value Realization Team Blog!
Going Mobile at Contoso Hospital (Delivery Documentary)
Establishing a Value Realization Center of Excellence (COE) at Contoso Bank (Delivery Documentary)
Security Strategy for Devices at Contoso Insurance (Delivery Documentary)
Business Transformation at Contoso Bank (Delivery Documentary)
Modern Apps at Contoso Health Insurance (Delivery Documentary)
When “Stop” is the Most Valuable Answer (Delivery Documentary)
When a company begins to use cloud services, it finds itself facing new challenges to its approach on security. Cloud-based services can affect many different aspects of security, ranging from the security features of new apps in development to the way a company defines the security measures for internal data.
The relative importance of each of these issues varies from company to company, depending on factors such as industry, regulatory environment, and the types of cloud services under consideration. Microsoft’s Enterprise Architects have helped a number of businesses adopt cloud-based services.
This article, based on the observations and experiences of Microsoft Architects, presents ten questions that can help your company identify security issues you may encounter when using cloud services.
1. How thoroughly has your organization defined its general security policy? Do you have platform-agnostic guidelines to apply as new security issues arise?
Without overall guidelines to fall back on, personnel may end up applying security measures ad hoc and interpreting applicable regulations on the fly. Microsoft Architects have worked with companies that operated in this manner—in such companies, the security measures applied to documents may depend more on where the documents are stored than their content.
For example, the protections applied in a web store may differ from those applied in another file share simply because different people were responsible for configuring them. A fractured security picture makes it very difficult for companies to specify which content may be used with cloud services and which content cannot be used with cloud services.
2. How flexible are your security systems? How much work will it take to accommodate the cloud-based service?
This work includes the technical changes needed to ensure that the cloud-based service can interact with your systems in the ways intended (and only those ways), and that the users have appropriate levels of access to the service.
Some companies have legacy technology that makes it difficult to modify security models and processes. For example, Microsoft Architects have worked with manufacturing companies, and have found that their systems tend to change more slowly than in other companies. As a result, these companies seem to accumulate legacy systems that tend to dominate any new technology and standardize approaches to issues such as security.
3. Do the Governance, Risk, and Compliance (GRC) requirements for your organization take cloud-based services into account? If not, do you expect them to change?
When using cloud-based services, some of the biggest challenges that businesses face relate to GRC requirements. Many businesses need to update their audit and compliance testing processes to account for transactions that may cross multiple environments.
Some regulatory agencies have not yet updated their requirements to account for cloud-based services. As a result, the companies they regulate face the choice of waiting to use cloud-services until the regulations are in place, or going ahead in the belief that the benefits outweigh the possible ramifications.
4. Is your IT organization accustomed to assessing value in terms of risks, costs, and benefits?
Microsoft Architects have observed that IT organizations become inflexible and risk averse when they become aware of risks without having a complete understanding of their context. These organizations find it difficult to change how they operate.
5. Are you building apps or APIs for customers or partners that incorporate cloud-based services?
Companies are using new approaches to partition functionality between LOB apps and cloud-based services, and to encrypt data that the cloud-based services process and store.
As customers become more comfortable using cloud-based services, companies that develop software and APIs that have strict security requirements are exploring ways to incorporate cloud-based services in a secure manner. Their customers expect the APIs to be sufficiently granular to meet their needs and able to keep their data secure as it passes through the cloud.
In the past, some businesses expected their customers would question the security of cloud-based apps and APIs. However, this resistance has dropped off over the past year.
6. Will your apps collect consumer information? How will you keep that information secure?
Based on what they have seen, some Microsoft Architects expect the issues of security and privacy to receive increasing legal and political attention as consumers evaluate how companies use the consumer data they collect.
7. Are you considering whether to add cloud capability to legacy applications?
Depending on the architecture of the legacy applications, it may be difficult to adapt them to work with cloud services.
8. Do you use a single identity management system for your company? Can this system (or multiple systems in use) integrate with cloud-based services?
Not all identity management solutions can integrate with cloud-based services, or federate with external identity stores.
9. Does your company organize data logically and classify it according to its security requirements?
If your employees will be using cloud-based services, you need to consider what company information will be involved. What information can pass through the cloud or be stored there? What information must stay on premises? How will you keep cloud-based information synchronized with on-premises information, and how will you protect it all? If you are allowing employees to use their own (unmanaged) devices with the cloud service, can you ensure that only appropriate information ends up on those devices?
Microsoft Architects have worked with many businesses who hadn't given much thought to their information architecture and classification systems before. Faced with unmanaged devices and cloud-bases services, they needed to analyze their content, streamline it, and classify it according to type, impact, and sensitivity. Further, they needed to develop an organizational system to make management tasks more feasible.
10. Are all levels of your business aware of the need to organize and secure data appropriately?
In many businesses, the IT organizations and upper levels of the business are aware of these concerns, but many levels of the business are not. The upper levels now have to work to drive that concern to the rest of their businesses. For example, employees that use web services to store documents at home occasionally use the same web services to store sensitive company documents, without considering deeper security implications.
This example, provided by Atul Totre, describes what happens when a Microsoft Architect finds that one of the projects he was called in to help with is not likely to produce the expected return on investment. What steps led to this finding, and what changes did the Microsoft Architect recommend to help the business succeed? Let’s find out…
A Microsoft Architect was called to help with a project that he assessed and found was not likely to produce the expected value. After thoroughly assessing the project and interviewing stakeholders, the enterprise architect presented his findings to the CIO and other top stakeholders. After reviewing and discussing the evidence, they agreed that continuing the project was not in the best interests of the business, and the resources involved could provide more value in other projects.
I began helping a business with a multi-year project to design and implement a new Identity and Access Management (IAM) system. The project had begun after an internal audit found that most of the IT systems failed the security compliance checks. The new system was supposed to replace the multiple identity systems currently in use at various facilities, to help bring the systems back into compliance with security standards.
Because the audit results had attracted attention within the company, the IAM project was well-funded, even though it was not expected to significantly change productivity. Its main impact was expected to reduce risk and improve understanding (and manageability) of the affected systems.
When asking for Microsoft’s help with the IAM project, the CIO expressed skepticism about the project’s progress. In the CIO’s opinion, the project was too big and there was a lack of structure in the approach of the internal project team. As the first priority, the CIO was looking for leadership and guidance from Microsoft to help:
After these steps were complete, the engagement could move on to redefining the strategy, roadmap, and plans for the IAM project.
For the first part of the engagement, I worked with five customer stakeholders and stakeholder groups:
Within a few weeks, I expected to have assessed the current state of the IAM initiative, including:
I also made a preliminary assessment of the expected (“To Be”) state of the IAM system following the current project. This assessment covered:
I also talked to the stakeholders and others to gain the perspective of the business on the IAM initiative. During discussions with the stakeholders, I also provided information about best practices for IAM strategy, as identified by Microsoft.
Following the assessment, I spent the next period on initiative planning and stakeholder workshops. The results of this planning process included roadmaps for business capabilities, the IT service model, and technology for the initiative for the current year, and a strategic roadmap for the initiative for the next 3 to 5 years.
To keep the stakeholders informed during the engagement, I regularly reported status:
I completed the first assessments, which included infrastructure optimization, maturity, compliance, as well as investment assessments, and a standard ESP initiative assessment. The information I gathered during this process helped me understand:
As I conducted my assessment and discussed it with business leaders and stakeholders, I began to see factors that contributed to the problems that the initiative was having.
I began a deeper examination of the IAM initiative based on my own perspective, knowledge, and experience. I found it to be a “horizontal” initiative that affected business groups throughout the organization, affecting operations throughout the organization. And it would cost a lot of money to implement. To succeed, the initiative must have support and ownership beyond the IT organization, and it must take the concerns and considerations of the business priorities into account.
In addition, I confirmed the CIO’s view that there was a lack of structure in the project team’s approach. In my experience, an initiative of this scope and size must be built on detailed structural analysis and strategic work, which was lacking.
To complicate matters, although the CIO had defined priorities for the IT organization, the strategies for supporting those priorities were not yet fully defined. Without those, it would be difficult to determine how to bring the initiative in line with those priorities (or if that realignment was even feasible).
I concluded that the business was unlikely to succeed with the current initiative, which did not directly address the needs of the business, and did not have enough support to succeed. The business would have to finalize strategies supporting its eight IT priorities, or face ongoing difficulties in defining a identity and access management solution that would be satisfactory across the business.
I presented my results to the CIO and the leadership team at their regularly scheduled meetings and used that forum to start the larger conversation about the identity and access management needs of the business. I shared my analysis, showing that the current path would not produce a solution that met the needs of the business, and I recommended that the business would be better off not spending money on a solution until having identified one with a better chance of success.
After reviewing my recommendations, the CIO agreed that the IAM initiative in its current form could not provide the needed return on investment, and he made the call to shelve the project.
The business also released the third-party consultants that had been helping with the IAM initiative, and redeployed its internal resources to address other initiatives:
What happens when an insurance company looks into modernizing business applications to increase productivity, improve customer service, and create a more easily supportable ecosystem for their employees and customers? Let’s see…
This is a Delivery Documentary of an engagement led by the Microsoft Enterprise Strategy Program (ESP), which provides services to help customers realize value from their technology investments. In this engagement, an Enterprise Architect helped Contoso Health Insurance develop a strategy to transform the business with mobile devices, and to rationalize and streamline the enterprise application portfolio.
The Enterprise Architect worked with a team of colleagues and subject matter experts (SME’s) to help stakeholders and end users envision a mobility strategy that would increase productivity and improve customer service. In addition, the team provided recommendations for adopting a modern application platform that would improve app hosting and enable agile development and testing of apps.
I was originally brought into Contoso Health Insurance by a Project Lead responsible for workstations, in response to new requirements for supporting mobility, and multiple devices and platforms. We continuously reported our status, findings, and recommendations to the Project Lead, even prior to formal presentations to stakeholders.
We also brought in different recognized industry and regional SMEs in health care, a mobility architect, IT strategy consultants, and Microsoft IT about our use of system center. We established peer-to-peer connections between the Microsoft IT department, and the IT department of Contoso Health Insurance. This quickly revealed many different perspectives about the issues, priorities, and pain points.
Before starting detailed discovery, we facilitated kick off meetings where the executive sponsors, CIOs, and CTOs presented their perspectives on business value. These views guided us through the engagement as we identified and compared value propositions of different possible initiatives.
We had many meetings with individuals, teams, and sub-teams to explore the areas in which we could make valuable changes. The discussions focused on productivity, optimization, and security. We were just finding out the lay of the land, not making recommendations yet. The breadth of topics was comprehensive, covering business processes, platforms, how apps are hosted, standards, security policies, industry trends, and more.
In some cases, we provided information and guidance from Microsoft SME’s. For example, we drilled more into the nature of information protection strategies, bring your own device strategies, and measuring results from such changes. The detailed guidance that helped at the beginning of the engagement included information about:
During the discovery process, we reviewed the pains and needs of the company as expressed by the CIO, CTO, and many stakeholders. We conducted activities to help executives and stakeholders envision their goals, and discussed business goals that could impact the architecture. We also presented some context about how our recommendations could be addressed, while maintaining a focus on business objectives.
To make the discovery process as efficient as possible, we first focused on capturing as much information as we could. We then took a short break from the process to gather additional data and perform analysis to support discussions of business value. After preparing a summary of our findings, we met again with executives and stakeholders to validate our findings.
The validation meetings revealed more about the details we needed to frame our recommendations, especially in emphasizing value to all stakeholders. For example, one discussion we had in the first week of discovery was around security and identity management. We found they had many security-related systems, each handling different aspects. There were also projects in progress for updating some of the systems.
When we analyzed this area, we found that a new overarching project was necessary to provide the desired benefits. When we met again to validate our findings, we talked to the security team and confirmed that we were on the same page with them about the value of these projects.
We created a report of our recommendations and presented it to our sponsor to review. After discussing the details with the sponsor, and other business leaders, we met with a broad audience. During the meeting we discussed what we had done so far, itemized the areas we looked at, described what we had found, and talked about the areas that we suggest receive the most focus.
Our presentation covered these topics:
We had an additional recommendations meeting with stakeholders who would be paying for the work. In this meeting we focused on the high value areas of work, quantitative measurements, the expected return on investment, and the cost. We identified a number of strategic changes that created a large enough value proposition to offset the cost of adding an architecture resource.
During this meeting, one of the company’s directors gave a presentation validating our work, providing additional support for our recommendations.
In summary, we proposed the following work streams, which a Microsoft Architect could help drive.
Application Rationalization
Numerous overlapping applications were deployed within different areas of the Contoso organization. Prior efforts to rationalize, integrate, or migrate applications had been unproductive; many applications no longer had active owners or anyone in the business with knowledge of how to modernize them. In some cases, IT had to maintain support for old operating systems on servers and workstations to enable outdated applications to continue working.
We proposed to rationalize the portfolio to identify apps to retire, and which apps they already have that can provide modern app capabilities they desire.
Modern Applications and App Hosting
There was no standardized app platform at Contoso, preventing effective mobile use of business apps, creating service-level problems, and hindering the creation of modern apps.
We proposed that moving to a platform that would enable modern apps, demonstrated prototypes and pilots from industry teams (such as healthcare and insurance), and quickly gained support from management to move forward on this work-stream.
We created a number of deliverables during the engagement in the process of collecting, analyzing, and presenting information:
Delivery Documentary: Contoso Hospital Goes Mobile
Delivery Documentary: Establishing a Value Realization Center of Excellence (COE) at Contoso Bank
Delivery Documentary: Security Strategy for Devices at Contoso Insurance
Delivery Documentary: Business Transformation at Contoso Bank
This article highlights some ways that businesses are using app stores, based on the experience and observations of Microsoft Enterprise Architects.
The following contributors provided input from the field: Blessing Sibanyoni, Brad Clayton, Brian Loomis, Johan Klut, Larry Hanthorn, Peter Deane, and Robbi Laurenson.
For both customers and employees, the numbers and types of available mobile devices have exploded. At the same time, increases in the availability of broadband access, decreases in latency, and a drop in telecom costs have made mobile devices easier and cheaper to use.
In their off-work hours, employees have access to public application stores, and have become accustomed to the flexibility and agility of quickly downloading the functionality they want on any device when they want it. They want this flexibility at work, too.
Many companies have found that their customers are also familiar with public app stores, and have come to expect that type of service.
To satisfy this demand, many companies are investigating how they can use app stores, both to deliver apps to their customers and to manage employee applications.
This article looks at three ways in which companies are using app stores, and several of the factors that affect the feasibility of an app store and the effort that might be needed to adopt one.
Most businesses that have implemented app stores use them for mobile apps. Now, new Windows features are leading some businesses to explore the idea of using enterprise app stores to distribute and manage software (more than just mobile apps) for employees.
Windows 8 includes features that make it app store-friendly, helping to make app stores a more feasible approach for distributing apps to desktops as well as to mobile devices. Public app stores (Windows Store, GooglePlay, and iStore) have been around for a few years. Now enterprises can use management systems such as System Center Configuration Manager to build private enterprise app stores that can control app versioning and usage reporting. For example,
Some businesses are using public app stores instead of building private enterprise app stores. In some cases, these businesses don't have a System Center Configuration Manager deployment on which to build; in other cases, businesses want the flexibility to offer apps not only to employees but also to public customers.
One bank produces a number of mobile apps for both customers and employees. The bank decided to use the app stores to make their apps convenient and easy to access for both customers and employees. The customer apps provide access to banking services. The employee apps help employees do their jobs. The bank maintains control of which apps are generally available, and which apps are restricted. The bank also can keep tabs on which apps are popular, and who is using them.
The bank's development team worked with these stores to customize access to and delivery of the apps. For example, they have built a federated trust relationship between the identity stores that the app stores use and the bank's own Active Directory store. As a result, employees can use their bank credentials for the app stores, and the bank can manage employees' access permissions using its own directory.
As a further benefit, the app stores can deliver apps to both company-owned and external devices. The bank described previously takes advantage of this flexibility to support a BYOD program for its employees—they can use their own devices, which are not fully managed by the IT organization.
This approach saves significantly on device management costs. The bank does maintain one aspect of device management; to maintain the security of corporate data, the bank uses a Mobile Device Management (MDM) system to identify employee devices; if a device is reported stolen, the MDM can wipe it remotely.
In working with businesses that are investigating or adopting app stores, enterprise architects have identified several factors that a company that is considering an app store must deal with:
How do you manage your current infrastructure?
App stores automate policies and processes that govern and track who installs which apps. In this function, they resemble other asset management systems such as System Center Configuration Manager. If you do not already have processes in place for distributing and managing applications, you should develop them in order to take full advantage of the app store's capabilities.
Enterprise architects in the field have observed that companies who do not have mature asset management systems, or even solid approaches for distributing and managing applications, find it difficult to adopt app stores.
Can you migrate your legacy applications, or would you use the app store only for new apps?
App stores typically support apps that are discrete units that function independently. This is not true of most line-of-business applications. Those applications tend to be large, complex, and integrated with each other. These characteristics do not lend themselves to an app store model. Some companies still have line-of-business applications that run on mainframes; these applications would be even more difficult to update to an app-like format that could work with an app store.
For these reasons, many companies view an app store as a Greenfield project--something to start from scratch to use with new apps rather than legacy applications.
Do you have the development capabilities to build or adopt an app store and the apps for it?
Adopting an app store requires some development resources and capabilities, whether you build an enterprise app store or use a public app store. Obviously, the capabilities you need to design and build an enterprise app store depend on the current state of your infrastructure.
On the other hand, the capabilities you need to adopt a public app store depend on the way in which you intend to integrate the app store with your own systems. This integration process may include customizing the access controls and tracking mechanisms that the app store uses to accommodate your company's needs. Whichever type of app store you use, you also need to consider the development capabilities you need for apps—new apps, migrated apps based on legacy applications, or both.
Can your existing staff supply these capabilities, or do you need to hire additional staff? What training would your staff need?
What impact would an app store have on your business processes and budgeting systems?
In addition to budgeting for the app store adoption and app development, you may need to consider updating the chargeback and recovery models that your company uses. For many companies, the IT organization is not the only part of the company that needs to change its processes to move to an app store.
For example, some companies distribute IT costs through the business using a charge-back model (assigning costs to business units depending on software installations within that business unit). For these companies, moving to an app store not only means changing the mechanisms that track who has what software, but also updating the accounting and budgeting methods. Some companies may need to change their budgeting assumptions, or even change whether certain budget items are considered OpEx or CapEx.
If it's within the capabilities of your company, an app store--public or private--can provide an effective and flexible means to distribute and manage apps. An app store can provide desktop or mobile apps to employee computers or devices. And depending on the type of store, they can also provide customers with easy access to apps that deliver your company's services.
Written by Martin Sykes and Paul Lidbetter, this post is a prelude to an article they will publish following the World Cloud Forum in June, 2014.
The McKinsey 2013 survey of business and IT executives found that the top technology priority was to improve business effectiveness and information availability.
However, as leaders become more aware of the critical strategic role of IT, the survey found that leaders are also becoming less satisfied with how effective IT is within their organizations, with just 13% of respondents being completely or very effective at introducing new technologies faster or more effectively than competitors, compared with 22% last year.
The overall focus for many was to increase spending and capabilities on analytics and innovation while reducing spending on infrastructure.
Driven by the growing demand for business digitization, mobile and on-line services, and a need to increase business impact, some line-of-business groups are taking local leadership for some application development and service procurement activities, thereby acquiring and running pockets of their own services and devices. This trend is sweeping away the long evaluation cycles for new technologies and large solution deployments of traditional IT organizations.
The services being acquired by line-of-business IT are coming from the cloud, where design and deployment are no longer challenges for the organization. Now, ensuring adoption, change management and operational oversight become key to realizing the value.
Based on this dynamic environment and the fast growing delivery of product and associated solutions through cloud channels, is the age of the big refresh project coming to end? How does the role of IT within an organization need to change? This is the theme of a paper I have been writing with a colleague recently, that will be published later this year. Here are a few thoughts from that paper that relate specifically to value realization.
There have been some significant changes in how people can acquire and deploy services and devices that challenge the traditional dominance of the IT department. The trends are:
Faster technology cycles, which are now changing within the year, results in business change being always behind the curve and hence the question 'is this still the right investment?' must be asked more frequently. If an organization cannot continually ask this question across its portfolio then not only will opportunities for growth, innovation and differentiation be missed but valuable assets will be wasted, losing competitive advantage.
Faster solution service cycles, with business solutions delivered over cloud services updating in some cases every month place pressure on organizations to decide how (or even whether) to adopt the new functionality as it becomes available. IDC believes that 82% of all net-new software firms will provide their software as cloud services.
Business agility is demonstrated every day as business groups buy services online or bring their own devices to work to rapidly take advantage of new opportunities. Business leaders would probably not talk in these terms, but the reality is they are trying to repeatedly achieve faster delivery of value on investments before competitors achieve competitive parity.
The bulk of traditional IT seems irrelevant to those outside the IT organization in the light of these trends. And yet this is just the start of the change that IT departments will need to adapt to.
EVERY year will beat the previous on the number of service releases until we reach the point where EVERY service changes at least once EVERY year and through cloud subscriptions lands on EVERY device for EVERY one of our users without the IT department having to do anything.
A value management culture becomes the new cornerstone to create the IT-Business foundation for the future to deliver repeated capability improvements for continuous competitive advantage. The portfolio of business investments in IT need to be managed by the value they will deliver, and no longer by the investment profile or internal resource constraints.
Value management drives new approaches to portfolio management as well as a culture change at the top. We believe that to be successful organizations will manage a value portfolio (as opposed to an investment portfolio) for IT to achieve faster business value cycles, with business intelligence supporting governance processes to identify the business capabilities with the greatest value potential.
As well as impacting the role of IT in the organization, such a change to managing value also drives the change to a more pervasive role for IT and a more value focused mind set for the organization as a whole.
As organizations move towards a Value Management/Adoption focus versus a Business Justification/Deployment mind set the message 'we delivered on time and budget' is assumed, the 'we co-delivered measured value to the business and customers' is the future focus. Project Management Offices (PMOs) will change from just tracking the cost of programs and projects delivered to the value realized in the business, with PMs including adoption and realization of value measures in the project scope.
We are not in the business of predictions, but we can say what we are seeing our leading customers do in response to the challenges we have described. Some of these changes are quite disruptive to the existing approaches IT departments have taken, especially where they have outsourced all of IT provision.
IT leaders are managing two portfolios, one with technologies and applications that have become commoditized and can be run at the lowest cost for a standard service, and one where the technology is providing business differentiation.
With the trend over the last 20 years to outsource IT provision there has also been a trend to focus on IT mainly as a commodity. Outsourcing organizations have had a hard time balancing the low costs required of them with the occasional requests for new projects and differentiating capabilities. We are now seeing a clearer separation in the IT strategic planning process of these portfolios and of the sourcing strategies for each portfolio.
With the growth of cloud, mobile, big data and social computing we are seeing organizations make critical information available to ever more people on more devices. This significantly increases the surface area for data loss, or theft. IT remains the central body that must have a firm handle on identity and security policies. It is also the organization that can provide secure access to shared information services, through internal APIs, to allow business units to create their own applications and modernize their own business processes.
Value is a core component of many business cases, but when approval is received and the project commences the project manager is typically focused on delivering to time and cost. The value component is lost.
In leading organizations the project and program managers are now tasked with delivering the value described in the business case, resulting in a trend for shorter projects with better definition of the change processes and adoption metrics for users of business capabilities enabled by the IT systems.
As more solutions are delivered from the cloud, with no IT deployment project, there is also a need for IT staff to focus on change management and user adoption techniques to ensure the user community is able to get value from the new features regularly appearing in the on-line solutions.
What happens when a Microsoft Architect and team help a bank explore ways to improve business operations, and to provide better service to an expanded number of customers? Let’s see…
This is a Delivery Documentary of an engagement led by the Microsoft Enterprise Strategy Program (ESP), which provides services to help customers realize the most value from their technology investments. In this engagement, an Enterprise Architect helped a large bank envision, articulate, and prioritize strategic initiatives supporting business transformation.
To maintain the reputation the bank has for innovation, the bank needed to address many challenges in streamlining architectures involving multiple IT shops, the complexity of a federated group organization, IT services that often did not scale well, and database resources needing consolidation.
The engagement began with discussions about the nature of enterprise services, continued as the Enterprise Architect made personal connections with stakeholders and sponsors, and culminated with the creation of the service delivery plan based on input from sponsors, together with guidance from a network of experienced and knowledgeable people around the world.
Contoso Bank chose Enterprise Strategy to help understand the business aspirations of the bank and the technology that can enable them. This relationship started with the cooperation of the Sales Executive, Account Manager and Enterprise Strategy Program Lead.
The Sales Executive pulled me in for a meeting with the head of architecture to discuss what Enterprise Services is, and how it could benefit the bank.
Next, I joined the major account manager for a meeting with the executive sponsor for the bank’s engagement, the managing architect, and the engagement manager, to discuss the topics of interest to the bank, and how Microsoft can help.
The bank had identified these topics as the priorities to address from a technology perspective as well as from the business, people, and process perspectives:
To learn the primary concerns of the bank prior to the kickoff workshop, I…
Participants represented security, network, end-user computing, retail, and other areas of the bank.
I led them through our thinking about what we do:
I focused on outputs and deliverables we’ve used before, and the results we’ve seen.
I spent time sharing my personal stories and experience with innovation in the banking industry.
I then validated the thinking of the participants about the themes they had identified. Since this is a very technical-oriented engagement, it was helpful to have the Account Technology Specialist at the meeting to conduct the technical dive required for each theme.
This activity helped me define the problem statements and the pain in order to prioritize and compile the service delivery plan. I identified the people feeling these pains, because these were the people who would be the champions of the initiatives.
Then I sat with the sponsors and asked “What does success for the program look like to you?”
I emphasized that the value we would deliver was not just about delivering documents, but helping them achieve their goals and get what they need faster. We may provide a POV, a strategic plan, an architecture plan, a business case, and so on.
The sponsors said it would be great to get help with:
This information helped me to identify the best ways to allocate resources to the project.
The lead asked to learn more about the capabilities that Office 365 offers, and to have us help him articulate the value of new capabilities. I reviewed the tradeoffs between flexibility and cost in private and public cloud deployments, explaining that private clouds still have service management issues, but you have flexibility and control. A public cloud is has the least amount of flexibility, but it is the most available, enables work from anywhere, and is the most cost effective. A hybrid approach offers middle ground.
I reviewed my findings with the executive sponsor and together we developed a delivery approach that expedited the highest priority work.
Using feedback from the workshop, meetings with sponsors, and consultations with Microsoft colleagues, I prepared a service delivery plan.
Currently, I’m taking deep dives into each of the initiatives to determine current state, capabilities, and context.