Intel vPro Expert Center Blog

3 Posts tagged with the automation tag
Click to view BobStoddard's profile
1

Manageability & Automation - It is all about planning!!!


How can Architecture help:

The primary role of architecture is to provide an orchestrated plan to meet short term and long term Manageability & Automation (M&A) objectives. Architecture is all about technical planning and can enable reduced operational costs and agility if done correctly. I strongly believe that architecture can help accelerate the rate of change and provide real value for "M" and for "A".

Some specific Architecture-enabling activities include:

  • Service Definition - Define the core Services and what are in/out Scope. Example below.

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1613/Scope.jpg

  • Taxonomy - Define the next level of Services details. Example below.

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1614/Taxonomy.jpg

  • Establish a high-level Strategy and Conceptual Architecture (5-10 year vision). Example below.

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1615/Architecture.jpg

  • Define a strategy with a set of guiding principles / policies to enable the M&A. These may include:
    • Vendor strategy (single / multiple sourcing)
    • Integration "Frameworks and/or Point Solutions" (or combo) strategy
    • Operation model strategy (centralized / distributed)
    • Data strategy


  • Define a 3-year horizon "capabilities" roadmap with the first year committed (partnership of Architecture, Operations and Engineering) and the last two years a best guess based on realistic funding, estimated vendor product delivery schedules, business trends, emerging / disruptive technologies, etc. Use this roadmap to communicate and synchronize with vendor roadmaps, driving your requirements into their products.


  • Establish governance to insure compliance to guiding principles and capability roadmaps.


  • Define specific detailed architecture (reference, service and solution) to connect the dots. Depending on the detail, they may include: logical diagrams, ports, protocols, product names, configuration standards, naming conventions, etc.


  • Be vocal when it comes to new concepts/technologies and push back it they do not make sense or pull if they do. In our enterprise, some worthy examples include: SOA, OS/Apps streaming, virtualization, IAMT.

We have seen architecture help. Two years ago, we started assembling an architecture plan (definition of the business, conceptual architecture and a capabilities roadmap). We focused resources and funding (consistent with the roadmap) on improving the "M" (Manageability) first. We have been very successful in key areas like compliance auditing, patching, basic autonomic responses to exceeded thresholds, etc. for servers and clients. We will focus the next couple of years on: increased "A" (Automated responses) and prevention for core platforms, integrating data (for business health reporting and enabling Automation), extending capabilities (like more event sources from storage and data center facility), extending remote management (IAMT), developing Capacity & Performance Mgt to a new level of sophistication and actively enabling automation to meet the operational business needs. The key is to have an agreed to vision and deliverables with some meat around governance to make it happen. This is more like a marathon, not a sprint.

I hope this was thought provoking.

Regards,

Bob

For context, Introduction of the "Relevance of Manageability & Automation Architecture" topic.

Supporting content is at:

Relevance of Architecture: Part 1 - Observations
Relevance of Architecture: Part 2 - Current Situation

1 Comments Permalink Tags: manageability, automation, architecture, datacenter
Click to view BobStoddard's profile
0


The current large computing enterprise is complex and difficult to manage. Architecture can help ... Part 2 highlights the current situation.


Current Situation:

I suspect that many large IT shops are struggling with the same problems, which may include some/all of the following components in their enterprise.

  • There are multiple hardware devices (rack servers, blade servers, switches, AP's, storage frames, NAS, SAN, appliances, desktops, workstations, laptops, small form factor devices, etc.) in the enterprise. All these devices run firmware/software that is not perfect and need to be managed.


  • Applications are tightly coupled to the platforms. This dependency needs to be understood and managed. The idea of a CMDB is appealing, especially where relationships can be defined and used.


  • There are hundreds of applications in the enterprise. Most of these applications were created, optimized and supported by specific teams or a Line of Business. Integrating these applications into the enterprise is difficult.


  • There are confusing/mixed operations models (some centralized, some distributed, some vertical, some horizontal, some a combination, some changing).


  • The desire for standard business processes in IT is high. ITIL appears to be a reasonable model to follow. Business processes (similar to applications) have historically been locally optimized and need substantial adjustment for the enterprise. This is complicated and difficult.


  • Enterprises implement a combination of vendor manageability products, "frameworks" (not really), point solutions and a lot of home-grown and/or open-source code. IT is the integrator of last resort.


Introduction of the "Relevance of Manageability & Automation Architecture" topic: http://communities.intel.com/thread/1564

" Part 1 - Observations" is posted at: http://communities.intel.com/openport/blogs/proexpert/2008/05/14/relevance-of-architecture-part-1-observations

0 Comments Permalink Tags: manageability, automation, datacenter
Click to view BobStoddard's profile
0

Introduction of the "Relevance of Manageability & Automation Architecture" topic: http://communities.intel.com/thread/1564

Observations

  • The real benefits of Manageability & Automation (M&A) in the enterprise distill down to reducing overall operational costs and providing more responsive / agile computing services. Capabilities in the Manageability space have matured (some nominally, some dramatically). Examples include: the speed and cost of deploying patches, the autonomic restarting of stopped services, out-of-band remote control, etc. Unfortunately, many Automation capabilities have been very slow to mature. An example is providing an automated capacity response to a demand signal for an application. We need to understand the overall capacity of the "data center" (server, storage, network, facility) and provision or move workloads consistent with demand of those applications / services following defined IT policies (e.g. ERP gets priority over e-mail in the last week of the quarter). We have a long way to go to make this "utility data center" happen.


  • The basic automation technologies are available, but the effort/expense to deploy them is too high (or at least perceived too high). We are still trying to solve many of the same TCO and agility problems from years ago. ROI or NPV deployment justifications do not show immediate benefit.


  • The basic computing models have not substantially changed. There are two basic categories of application usage models. There are local "PC" applications that create/view content and enterprise applications that help execute business processes. Technologies like "application/OS streaming", PXE network boot, etc. are creative methods for packaging and delivering the needed bits to the destination for execution.


  • The industry has complicated these two usage models by introducing multiple device form factors, multiple operating systems, network enclaves, roaming connectivity, restricted permissions, secure communications, virtualization, SOA, new delivery models (like streaming), etc.. All of this must be managed.


  • For enterprise applications, instrumenting the components (clients, networks, servers, services and the application) provides value, but is incomplete. Manageability needs to consider all aspects of the "user experience" to provide major benefit. The whole is truly larger than the sum of the parts.


  • Manageability vendors need to sell product, which requires differentiation. There is little vendor incentive to provide "standard" products, unless they can supplement those standard offerings with their specific differentiators. Although "adapters", scripting extensions, APIs, etc. are available, it is still very complicated and expensive to implement.

0 Comments Permalink Tags: manageability, automation, architecture, datacenter