Type A, B and C Enterprises

Type A, B and C Enterprises

A Gartner framework that classifies enterprises or their subdivisions according to a technology adoption profile. Classification is based not only on an enterprise’s current technology adoption strategy, but also on whether the strategy is supported by senior management and is adequately funded.

  • Type A enterprises are typically technically aggressive and well-funded, and use IT to gain a competitive advantage.
  • Type B enterprises, which are in the majority, are mainstream IT users with adequate funding that use IT for productivity.
  •  Type C enterprises are technologically conservative and risk-averse, and seek to control IT costs.

Recognizing an enterprise’s type offers company strategists a meaningful way to compare an enterprise’s use of technology against that of competitors, and to make decisions about when, how and where to adopt new technologies.

ICT Architecture Titles by Deliverables

ICT Architecture Titles by Deliverables

 

As a Solutions Architect, I always like to think outcome or deliverables based. So here is a short description of ICT Architecture Titles by Deliverables. There seems to be a lot of confusion around these titles so hope this helps.

These titles vary depending where the nominated titles is allocated inside ICT Supply Chain. (Customer, MSP, Vendor, Solutions Integrator or Distributor) more on this here:- http://www.insidespin.com/channeltopics.php#resellers .

(Loosely based on TOGAF and Zachman)

ICT Architecture Titles and Deliverables

  1. Presales / Sales Engineers (Vendors and SI side only)
    • Competitive Selling
    • Proof of Concepts/Pilots/Health Checks
    • Product Selection / Commercial and Licensing Models
    • Bill of Materials
    • Account Planing
    • Customer Training
  2. Enterprise Architects (Usually only customer side) Quasi CIO level
    • Business Case
    • Strategy/Financial Justifications (ROI, TCO, Net Present Value, RPO/RTOs)
    • Project Managment
    • RFP / RFI Scoping
    • Risk and Governances
    • Technology Roadmaps
    • Reference Architectures
    • Vendor Selection
    • Architecture Practices
    • Sourcing Agreements
    • Service Level Agreements
  3. Solutions Architects/Domain Architects (Infrastructure/Application/Security)(Customer, Vendor or SI)
    • Infrastructure Requirements
    • Responding to RFI/RFPs
    • Statement of Work
    • High Level Design
    • Bill of Materials
    • Services Estimates
  4. Subject Matter Experts (Delivery Focused)
    • Low-Level Design
    • As-Built Documentations
    • Operating Manuals

This is Rule of Thumb only.

Reference

The 10 Laws of Cloudonomics

The 10 Laws of Cloudonomics

In 2008, Joe Weinman, then Strategic Solutions Sales VP for AT&T Global Business Services, created the 10 Laws of Cloudonomics22 that still, after two and a half years, are the foundation for the economics of Cloud Computing. We’ve reproduced an abridged version of the Cloudonomics laws below.

Cloudonomics Law #1: Utility services cost less even though they cost more. Although utilities cost more when they are used, they cost nothing when they are not. Consequently, customers save money by replacing fixed infrastructure with Clouds when workloads are spiky, specifically when the peak-to-average ratio is greater than the utility premium. Cloudonomics Law #2: On-demand trumps forecasting. Forecasting is often wrong, the ability to up and down scale to meet unpredictable demand spikes allows for revenue and cost optimalities. Cloudonomics Law #3: The peak of the sum is never greater than the sum of the peaks. Enterprises deploy capacity to handle their peak demands. Under this strategy, the total capacity deployed is the sum of these individual peaks. However, since Clouds can reallocate resources across many enterprises with different peak periods, a Cloud needs to deploy less capacity. Cloudonomics Law #4: Aggregate demand is smoother than

Cloudonomics Law #2: On-demand trumps forecasting. Forecasting is often wrong, the ability to up and down scale to meet unpredictable demand spikes allows for revenue and cost optimalities. Cloudonomics Law #3: The peak of the sum is never greater than the sum of the peaks. Enterprises deploy capacity to handle their peak demands. Under this strategy, the total capacity deployed is the sum of these individual peaks. However, since Clouds can reallocate resources across many enterprises with different peak periods, a Cloud needs to deploy less capacity. Cloudonomics Law #4: Aggregate demand is smoother than

Cloudonomics Law #3: The peak of the sum is never greater than the sum of the peaks. Enterprises deploy capacity to handle their peak demands. Under this strategy, the total capacity deployed is the sum of these individual peaks. However, since Clouds can reallocate resources across many enterprises with different peak periods, a Cloud needs to deploy less capacity. Cloudonomics Law #4: Aggregate demand is smoother than

Cloudonomics Law #4: Aggregate demand is smoother than individual. Aggregating demand from multiple customers tends to smooth out variation. Therefore, Clouds get higher utilization, enabling better economics.

Cloudonomics Law #5: Average unit costs are reduced by distributing fixed costs over more units of output. Larger Cloud providers can therefore achieve some economies of scale. Cloudonomics Law #6: Superiority in numbers is the most important factor in the result of a combat (Clausewitz). Service providers have the scale to fight rogue attacks.

Cloudonomics Law #6: Superiority in numbers is the most important factor in the result of a combat (Clausewitz). Service providers have the scale to fight rogue attacks.

Cloudonomics Law #7: Space-time is a continuum. Organizations derive competitive advantage from responding to changing business conditions faster than the competition. With Cloud scalability, for the same cost, a business can accelerate its information processing and decision-making. Cloudonomics Law #8: Dispersion is the inverse square of latency. Reduced latency is increasingly essential to modern applications. A Cloud Computing provider is able to provide more nodes, and hence reduced

Cloudonomics Law #8: Dispersion is the inverse square of latency. Reduced latency is increasingly essential to modern applications. A Cloud Computing provider is able to provide more nodes, and hence reduced latency, than an enterprise would want to deploy.

Cloudonomics Law #9: Don’t put all your eggs in one basket. The reliability of a system increases with the addition of redundant, geographically dispersed components such as data centers. Cloud Computing vendors have the scale and diversity to do so.

Cloudonomics Law #10: An object at rest tends to stay at rest. A data center is a very large object. Private data centers tend to remain in locations for reasons such as where the company was founded, or where they got a good deal on property. A Cloud service provider can locate greenfield sites optimally.

 

Sizing Backup/Data Protection Solutions

Sizing Backup/Data Protection Solutions

  • RPO/RTO
  • Applications
    • VM
    • File – Unstructured
    • DBs  – Structured
    • OS
    • Physical
    • (Front Side data)
    • NAS/NDMP
    • Agents
  • Targets
  • Retention (LTR/Legal hold)

Features

  • RPO/RTO
  • Deduplication/Compression
  • Rate of Change
  • NDMP Integration
  • Front Side File
  • Front Side Database
  • VMware Used
  • NAS/NDMP
  • Array Integration
  • LAN-Free
  • Encryption (In flight / At rest)
  • VMware vStorage API for Data Protection (VADP) / Copy Blocks
  • Span Shots / Replication
  • Daily ( 7 Days Retention)
  • Weekly (4 weeks Retention)
  • Monthly (7 Years Retention)
  • Annual (7 Years Retention)
  • Backup vs Archival

 

Solutions

  • VMware Data Protection
  • Avamar Virtual Edition / Business Editions Appliance
  • Data Domain Appliance
  • BaaS
  • Replication as a Service
  • DRaaS

 

Deployment

  • Rack and Stack Appliance
  • Switch Configuration
  • Initial Avamar Configuration
  • Install Avamar Windows Administration VM and Application
  • Deploy Avamar Proxy VM on each VMware vSphere vCenter Cluster
  • Deploy SSL Certificate
  • Migration and Injest of existing DBs
  • Configure Backup Schedules
  • Deploy DDBoost and Avamar DB Plug-ins
  • Deploy Agents
  • As-Built Documentation
  • Detailed Design
  • Acceptance Testing
  • Backup and Restore User Guide

Research