Scrum vs Traditional Project Management

	Scrum	Traditional PM
Emphasis is on	People	Processes
Documentation	Minimal	Comprehensive
Process style	Iterative	Linear
Upfront planning	Low	High
Prioritization of Requirements	Based on Business Value and regularly updated	Fixed in Project Plan
Quality assurance	Customer Centric	Process Centric
Management Style	Decentralized	Centralized
Change	Updates to Productized Product Backlog	Formal Change Management System
Leadership	Collaborative, Servant Leadership	Command and Control
Performance Measurement	Business Value	Plan Conformity
Return on Investment	Early and throughout project life	End of Project Life
Customer Involvement	High Throughout the project	Varies depending on project lifecycle

Why Use Scrum?

Some of the key benefits of using Scrum in any project are:

• Adaptability—Empirical process control and iterative delivery make projects adaptable and open to incorporating change.
• Transparency—All information radiators like a Scrumboard and Sprint Burndown Chart are shared, leading to an open work environment.
• Continuous Feedback—Continuous feedback is provided through the Conduct Daily Standup, and Demonstrate and Validate Sprint processes.
• Continuous Improvement—The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized Product Backlog process.
• Continuous Delivery of Value—Iterative processes enable the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.
• Sustainable Pace—Scrum processes are designed such that the people involved can work at a sustainable pace that they can, in theory, continue indefinitely.
• Early Delivery of High Value—The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.
• Efficient Development Process—Time-boxing and minimizing non-essential work leads to higher efficiency levels.
• Motivation—The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.
• Faster Problem Resolution—Collaboration and colocation of cross-functional teams lead to faster problem solving.
• Effective Deliverables—The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.
• Customer Centric—Emphasis on business value and having a collaborative approach to stakeholders ensures a customer-oriented framework.
• High Trust Environment—Conduct Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.
• Collective Ownership—The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.
• High Velocity—A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity.
• Innovative Environment—The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

Technical Co-Founder Wanted for Social Healthcare Startup

My friend and successful entrepreneur Emily White is looking for a Technical Co-Founder to help execute her new venture in social healthcare. She has intellectual property and ready markets. She is building her team and is looking for the right person to lead the technical development. Could it be you?

Heroic People Emily White, Founder/ CEO

Problem

Sixty five (65.7) million caregivers make up twenty nine percent of the U.S. adult population providing care to someone who is ill, disabled or aged. [The National Alliance for Caregiving and AARP (2009), Caregiving in the U.S. National Alliance for Caregiving. Washington, DC.] - Updated: November 2012 Half of them are employees, many are long distance and all of them have urgent questions.

Most family members and older adults do not know even know what resources are available or what to look for in an answer because they are under so much stress and overwhelmed.

We have a patented solution with validated business process and methodology including telehealth and would love to meet folks who have:

1. passion about the field of aging
2. hands on mobile with audio-video, web experience with successful launches
3. experience leading a team
4. Hippa compliance experience
5. creative, strategic, super smart

Please contact emily@heroicpeople.org

Worst Methods for Enterprise Architecture

On the opposite side of the spectrum, Burton outlined her baker’s dozen of “worst” enterprise architecture practices. The EA methods that Burton said muddied efforts and missed overall business returns are as follows:

1. No link to business strategic planning and budget process.

2. Confusing "IT Architecture" with "Enterprise Architecture."

3. Lack of governance.

4. Too much standardization.

5. Focusing on the art/language of EA rather than the outcomes.

6. Strictly adhering to architectural frameworks.

7. An "Ivory Tower" approach by IT and EA team members.

8. Lack of communication and feedback.

9. Limiting the teams to IT resources.

10. Missing performance measures.

11. Picking a tool before understanding business needs.

12. Focusing on the current state first and primarily.

13. Thinking that implementation equals completion.

via information-management.com

What is Enterprise 2.0?

Enterprise 1.0	Enterprise 2.0
Hierarchy	Flat Organization
Friction	Ease of Organization Flow
Bureaucracy	Agility
Inflexibility	Flexibility
IT-driven technology / Lack of user control	User-driven technology
Top down	Bottom up
Centralized	Distributed
Teams are in one building / one time zone	Teams are global
Silos and boundaries	Fuzzy boundaries, open borders
Need to know	Transparency
Information systems are structured and dictated	Information systems are emergent
Taxonomies	Folksonomies
Overly complex	Simple
Closed/ proprietary standards	Open
Scheduled	On Demand
Long time-to-market cycles	Short time-to-market cycles

The Principles of the Global Workforce

1. Distance doesn’t matter.

Employees now expect to be able to collaborate in real-time with any co-worker. They expect to have access to whatever data or services the company offers no matter where they happen to be. Where in the world that co-worker actually works is irrelevant. They may be working from home, different offices, at airports, manufacturing facilities, or even on a ship somewhere. Knowledge workers need the flexibility to work wherever they must in order to best complete their jobs. That may mean on-site, at a customer’s office, or even from the quiet of their own home. IT must be an enabler for the way business needs to operate. Waiting 20 minutes for a file to be sent between workers – even if they are across the world from each other – is no longer acceptable for the employee or for the customer project that they are working on.

2. Business never stops.

With a globalized workforce – and a rapidly globalizing customer base – businesses cannot afford their operations to be stopped for even a few minutes. Responsiveness to disaster or failure – often characterized by recovery point objective (RPO) and recovery time objective (RTO) – must go far beyond responding to common problems like a failed SAN or a downed fiber connection. Issues like hurricanes or a flu pandemic might force workers to operate from home for an unspecified period of time. Compromised data centers may require enterprise to rapidly switch operations to secondary locations with no loss in information.

3. Applications and data must be available everywhere but all in one place.

With organizations working harder to protect their valuable data and sensitive customer information, many IT organizations are engaging in IT consolidation projects. Consolidating data makes it easier to track, protect, and restore. Beginning with remote tape backup and progressing to more complicated projects like file servers, document management applications, PLM systems, and Web applications, CIOs are demanding that data be brought back from remote offices. At the same time, businesses recognize that the data and applications were “out there” for a reason – that’s where they needed to be accessed. So while consolidation is an important strategy for data protection and cost control, it can negatively impact business operations unless LAN-like performance can be maintained everywhere.

4. Knowledge must be harnessed – and data must be managed.

Consolidation goes a long way to eliminating the islands of storage and data that evolve over time. But with organizations being required to react quickly in the face of
change, or move in order to take advantage of an opportunity, flexibility in moving data and applications is essential. CIOs must be able to quickly move massive amounts of data, and potentially set up application infrastructure in remote locations overnight. New offices and merged/acquired businesses must quickly be absorbed into the fabric of the existing organization by providing them immediate access to new systems and data.

5. There are no second-class enterprise citizens.

The days of the “important” people working at corporate HQ are rapidly fading. Employees everywhere are now empowered to make important decisions. Whether it is designing or manufacturing a product, working with a customer, or working on a localized version of an advertising campaign, work happens everywhere. And the work of the distributed employee isn’t less important than anyone else’s work. Just as importantly, these workers need to interact with their colleagues, applications and data everywhere. CIOs and IT managers may no longer prioritize workers based on their geographic location. Every member of the enterprise needs to have access to the same applications, at the same level of application performance.

from "The CIO's new guide to design of global IT infrastructure"

Cynefin Framework

The Cynefin framework has five domains. The first four domains are:

• Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense - Categorise - Respond and we can apply best practice.
• Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply good practice.
• Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
• Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act - Sense - Respond and we can discover novel practice.

The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.

via en.wikipedia.org

7 Primary Business Drivers for Social Media

• Enhance branding and awareness
• Protect reputation
• Extend public relations
• Build community or loyalty
• Extend customer service
• Facilitate research and development
• Drive sales or leads

via briansolis.com

 

connect with me

Cloud Decisions

• Evolution rather than replacement.
The private cloud can evolve from existing virtualized infrastructure, enabling the transition to cloud computing without a complete and disruptive infrastructure overhaul.
• Security and compliance.
With a private cloud, data is retained within the enterprise, behind the corporate firewall, where IT can exercise full control over security, privacy, and regulatory compliance. With public clouds, enterprise data is housed in external data centers—and may move from location to location, without IT’s knowledge or consent. The dynamic movement of data in a public cloud may also present compliance challenges with local regulations.
• Service level agreements (SLAs).
Keeping applications in-house can help IT continue to meet SLAs deining performance, availability, and other critical business requirements. Some external providers may not be able to furnish the same level of service.
• Cost.
A large enterprise private cloud can provide economies of scale, resulting in total cost of ownership (TCO) that is competitive with or lower than public clouds. Intel IT, for example, found that services can be hosted internally at equal or lower TCO than hosting them externally.
• Building expertise.
Architecting a private cloud enables IT organizations to develop a knowledge base that can be applied to public clouds in the future. When creating the private cloud, IT will need to develop detailed application and data inventories, and gain key skills such as managing cloud SLAs. This experience will help build effective relationships with public cloud providers, enabling IT organizations to assess whether they meet enterprise requirements

(excerpt from http://www.readwriteweb.com/cloud/cio-agenda-paper-vmware.pdf)

connect with me

Social Network Users' Bill of Rights

1. Honesty: We will honor our privacy policy and terms of service.

2. Clarity: We will make sure that our policies, terms of service, and settings are easy to find and understand.

3. Freedom of speech: We will not delete or modify user data without a clear policy and justification.

4. Empowerment : We will support assistive technologies and universal accessibility.

5. Self-protection: We will support privacy-enhancing technologies.

6. Data minimization: We will minimize the information users are required to provide and share with others.

7. Control: We will work toward enabling users to own and control their data and won’t facilitate sharing their data unless they agree first.

8. Predictability: We will obtain the prior consent of users before significantly changing who can see their data.

9. Data portability: We will make it easy for users to obtain a copy of their data.

10. Protection: We will treat user data as securely as our own confidential data unless they choose to share these data, and notify them if these data are compromised.

11. Right to know: We will show users how we are using their data and allow them to see who and what has access to their data.

12. Right to self-define: We will allow users to create more than one identity and use pseudonyms. We will not link them without their permission.

13. Right to appeal: We will allow users to appeal punitive actions.

14. Right to withdraw: We will allow users to delete their accounts and remove their data.

via blog.diasporafoundation.org

 

connect with me

The 5 Laws of Engagement

Law 1: We seek comfort in relationships: Surround us with community, which we’ve seen success with like Facebook, Twitter and 4chan. Most interestingly is PostSecret, an ongoing community art project where people mail in their secrets anonymously on one side of a homemade postcard.

Law 2: We all have something to say. So give us tools to express ourselves. Tools include comments, notes, and all the fun things Facebook has given us with Timeline, etc.

Law 3: We need to feel important. Use rewards to make us feel special. How do you make people feel special? One way is through exclusivity like Gilt Group. One way is through badges on Foursquare.

Law 4: We are hypnotized by beauty. Give us something beautiful to look out. Flipboard puts the image first. Instagram is a series of beautiful images within a community.

Law 5: We are captivated by the unknown. So target our curiosity. Foursquare does this with points! Pinterest does with page after page of constant intrigue.

via thenextweb.com

 

connect with me

Anne Boe's Keys to Successful Networking

1. Clarify your career goals.
2. Develop long-term win-win relationships.
3. Nurture your network daily.
4. Be actively involved in your community.
5. Meet as many people as you can.
6. Take your business cards everywhere.
7. Make friends, even when you don't need them.
8. Act like a host, not a guest.
9. Become an interested person.
10. Develop your listening skills.
11. Trust your intuition.
12. Take people risks.
13. Master the art of small talk.
14. Work smarter, not harder.
15. Value yourself and your life.
16. Take action daily towards your goals.
17. Become your own energy manager.
18. Learn to ask for what you want.
19. Give thanks for what you have.
20. Acknowledge your skills and talents.
21. Say "Thank you. "
22. Become an inverse paranoid - decide the world is conspiring for you.
23. Determine your priorities - protect your energy.
24. Learn to want what you have.
25. Know that there are more side doors in the world than there are front doors.

[Source: Anne Boe]

connect with me

Creating an IT Strategy - Management by Maxim

I have heard that 90% of all businesses do not have a written Business Strategy.  Its in their heads - but as an Enterprise Architect how do you extract it so that you can create a viable IT Strategy?  Often times CxOs don't have time to have a strategic dialogue.  One way to solve this problem is to employ the "Maxim Process"
The Maxim Process is described by Broadbent and Kitzis as a pragmatic way to extract enough information for a good enough IT strategy while not investing more than a day’s workshop with senior management. The CIO will organize a workshop with CxOs, which will lead to documenting 2 kinds of so-­‐called Maxims:

• Business Maxims
• And as a result IT Maxims

Maxims are a few concise principles that are used to document the strategic direction of an enterprise. A Maxim workshop will usually not produce more than around 5 business maxims. For each of those, management will derive 4-­‐5 maxims for the IT function that will help to support them.

A typical Maxim Workshop will be split up into two parts:

• Part 1: Finding the Business Maxims,
• Part 2: Deriving the IT Maxims

An external facilitator should moderate the workshop day and process.
To give examples imagine an old economy financial service provider like a big insurance company that runs more than one brand name on the market. For such an enterprise you could find the following business maxim:

• Create synergies in back office and service functions wherever brand identity is not compromised

IT maxims that could be deducted from such a business strategy could be:

• Define standard architectures and platforms used by all of the group’s companies in order to leverage synergies and to reduce IT cost
• Harmonize the IT application systems for the group’s companies wherever there is a business case for this.

SOURCE: TOGAF9 QuickStart Guide 2009

connect with me

Eight Hybrid Thinking Principles for Enterprise Architects

1. Coordinate from the outside in. Once the "outside" design is in place, it serves to guide the foundation for inside structures.
2. Pursue a portfolio of strategies.   Evaluate many small bets instead of single large ones
3. Harmonize, rather than optimize.  Enterprise architects learn to focus on "harmonizing" a diverse set of existing approaches and less on creating an optimal approach from scratch.
4. Coordinate, rather than architect.  Hybrid thinking approaches view the enterprise as a collection of interdependent portfolio management processes, with the goal of coordinating across and among these portfolios.
5. Focus on interactions, not interactors.   Hybrid thinkers must focus on coordinating the behaviors among systems rather than optimizing the internal mechanisms of such systems.  Gartner sometimes refers to this approach by the phrase "architect the lines, not the boxes." "Lines" refers to behaviors shared among systems, and "boxes"
6. Embrace a different approach to standards.   The focus shifts from thinking of standards as "inhibitors of choice" to "enablers of change." Hybrid thinkers emphasize that the purpose of standards is to enable coordinated interactions and behaviors to change and evolve.
7. Encourage continuous and participatory interaction.  Hybrid thinking charrettes enable individuals to overcome traditional process barriers by fostering more collaborative, creative and meaningful outcomes. Design is done best when it is peer to peer.
8. Focus on business outcomes, not IT outcomes.

Source: Gartner 2010

connect with me

What Does an Enterprise Architect Do ?

Business Technology Strategy
What You Know	What You Do	What You Are
Your organization’s business and technology strategy and rationale Your competition (products, strategies and Processes) Your company’s business practices Your Technology Portfolio	Influence business strategy Translate business strategy into technical vision and strategy Understand customer and market trends Capture customer, organizational and business requirements of architecture Prepare architectural documents and presentations	Visionary Entrepreneurial

 

Organizational Politics
What You Know	What You Do	What You Are
Who the key players are in the organization What they want, both business and personal	Communicate, Communicate, Communicate Listen, network and influence Sell the Vision, keep the vision alive Take and retake the pulse of all critical influencers of the architecture project	Able to see from and sell to multiple viewpoints Confident and articulate Ambitious and driven Patient and not Resilient Sensitive to where the power is and how it flows in your organization

 

Consulting
What You Know	What You Do	What You Are
Elicitation techniques Consulting frameworks Soft Skill techniques	Build “trusted advisor” relationships Understand what the business people want and need from the architecture Understand what the developers want and need from the  architecture Help developers see the value of the enterprise architecture and understand how to use the technology successfully	Committed to others’ success Empathetic and approachable An effective change agent and process savvy A good mentor and teacher

 

Leadership
What You Know	What You Do	What You Are
Yourself	Set team context and vision Make decisions stickp> Build teams Motivate	You and others see you as a leader Charismatic and credible You believe it can an should be done and that you can lead the effort Committed, dedicated, passionate You see the entire effort in a broader business and personal context

 

Technology
What You Know	What You Do	What You Are
In-depth understanding of the domain and pertinent technologies Understand what technical issues are key to success Development of methods and modeling techniques	Modeling Trade-off Analysis Prototype, Experiment, and Simulate Prepare architectural documents and presentations Technology trend analysis/roadmaps< Take a systems viewpoint	Creative Investigative, Practical, Pragmatic, and Insightful Tolerant of ambiguity, willing to backtrack, seek multiple solutions Good a working at an abstract level

 

Risks and Rewards
Risks	Rewards
Responsibility without corresponding control A lot of resistance and disappointments along the way Often encounter others that believe they have a better idea or solution	Focus on interesting and complex issues Opportunity to advance to very high levels in the organization with business and technical focus (rather than personal and fiscal) Opportunity to make an enormous difference to the company and clients

Source: IFEAD

connect with me

What is the difference between Architecture and Design?

Architecture	Design
Essentials dictated by the mission (problem, need or opportunity) and its environment	Decisions compatible with the architecture
A different architecture implies a different mission	Different designs may address the same mission
Defines a class of acceptable solutions	Defines a single specific solution
About suitability or fitness for purpose, as defined by the mission	About engineering optimization, within architectural constraints
Role of the architect is mostly to make correct inferences about the mission, solution and environment	Role of the designer is mostly to make correct decisions about the solution
Architecture is done by architects	Design is done by developers
Primary audience is mission and solution stakeholders, which usually includes designers and implementers	Primary audience is solution implementers
About the mission and solution in their environmental context, i.e., outward looking	About components and subsystems of the solution, i.e., inward looking

connect with me

Kim Cameron's 7 Laws of Identity

1. User Control and Consent:
Digital identity systems must only reveal information identifying a user with the user’s consent. 
2. Limited Disclosure for Limited Use
The solution which discloses the least identifying information and best limits its use is the most stable, long-term solutio.
The Law of Fewest Parties
Digital identity systems must limit disclosure of identifying information to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity
A universal identity metasystem must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.  
5. Pluralism of Operators and Technologies:
A universal identity metasystem must channel and enable the interworking of multiple identity technologies run by multiple identity providers.  
6. Human Integration:
A unifying identity metasystem must define the human user as a component integrated through protected and unambiguous human-machine communications.  
7. Consistent Experience Across Contexts:
A unifying identity metasystem must provide a simple consistent experience while enabling separation of contexts through multiple operators and technologies.

via idcommons.org

connect with me

Ten Topics a Venture Capitalist Cares About

According to Guy Kawasaki The ten topics that a venture capitalist cares about are:

1. Problem
2. Your solution
3. Business model
4. Underlying magic/technology
5. Marketing and sales
6. Competition
7. Team
8. Projections and milestones
9. Status and timeline
10. Summary and call to action

[Image courtesy of FreeDigitalPhotos.net]

connect with me

Guiding Principles for Enterprise Architects

Minimalist Architecture Principle

Essentially, the Minimalist Architecture Principle says “if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.” This means that architects only make decisions that require the overall perspective and authority that the architect has. If a decision has local impact, then the architect has no need to mess with it. If the decision has broad impact, and the impact has highly strategic consequences, then the decision fits the minimalist architecture criterion.

Minimalist Architecture Principle: Make only those decisions that have to be made at this level of scope to achieve the business strategy and meet the architecture objectives and vision.

Decisions With Teeth Principle

Another way of pruning the Enterprise Architecture decision set is to apply the Decisions with Teeth Principle. Decisions that have teeth are those that are both enforceable and enforced. They can and will be adhered to, and if not, there will be consequences. This means that the decisions must be well-formed. They have to be unambiguous and have a clear scope of applicability. And there must be a governance process that allows for discovery of breaches and determines consequences, rather than simply granting exceptions.
Too often, architects and their deployment communities treat enterprise architecture decisions as statements of “general good.” These decisions are treated like guidelines or suggestions, which other architects, designers or implementers choose whether or not to follow. Such decisions have no teeth.
This may highlight a need to improve your governance process, but even with a strong governance process in place, objections raised in the name of customer advocacy have a powerful shield. That is, arguments in favor of the “general good” are susceptible to counter-arguments made in the name of a customer or immediate concern.

The reason to avoid making decisions that are likely to be dismissed is simple: you do not want the whole Enterprise Architecture to be tarred with the failure brush for the sake decisions that will be ignored and/or cannot be enforced. Further, it is a waste of time for the architect to make, and for others to think about and then ignore, such decisions.

Decisions With Teeth Principle: Only include decisions in your Enterprise Architecture that you, and the governance organization, are willing and able to enforce.

Connect-the-Dots Principle

This presents a conundrum which is resolved by applying another principle, which we call Connect-the-Dots. According to this principle, each architecture decision must be rationalized in terms of business goals, architecture requirements, or higher-level architecture decisions. You see, the only voice that stands any chance of holding its own against the voice of the customer is the voice of the business. Business strategy represents the voice of the business, and connect-the-dots creates a compelling chain that links business strategy to architecture goals to architecture decisions.
At its best, business strategy is well grounded in the voice of the customer and it is grounded in the voice of the business telling the story of competitive differentiation. It takes into account the competitive environment, the value network, internal capabilities and financial goals. Enterprise Architecture that takes business strategy as its starting point, and shows how each architecture decision is necessary to achieve the business strategy, expresses the voice of the business, and follows the connect-the-dots principle.

When the case has been made that the enterprise architecture decisions satisfy these three principles, then that set of decisions can be described as the technical expression of the business strategy. When such a decision, clearly driven by the business strategy, is ignored, we need to realize that it is not the architecture that is being brought into question, but the strategy itself. This focuses discussion where it belongs. The overall business strategy, like the enterprise architecture, optimizes across the organization. We need to not get distracted by debate about technology questions when the real issue is clarifying and enforcing what is strategic to the business.

Connect-the-Dots Principle: There must be a traceable connection from business strategy to each enterprise architecture decision

via bredemeyer.com

connect with me

NIST Definition of Cloud Computing

On-demand self-service.
A consumer can unilaterally provision computing capabilities, such asserver time and network storage, as needed automatically without requiring human interaction with each service’s provider.
Broad network access.
Capabilities are available over the network and accessed through standardmechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,mobile phones, laptops, and PDAs).
Resource pooling.
The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact
location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.
Rapid elasticity.
Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
Measured Service.
Cloud systems automatically control and optimize resource use by leveraging a metering capability1 at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.