elemental links

@ Enterprise 2.0 Evening in the Cloud Panel discussion

[update: 6.23.2009 - "MIT CIO Symposium Organizer" is Christopher Reichert]

David Berlind is our Evening in the Cloud host.  David says the discussion shouldn’t be about cloud computing definition, it should be about cloud computing benefits.  The benefits will lead to the ‘right’ definition.

Evening format is a panel discussion, followed by networking and speed geeking demos to win over our virtual $1 million.

I’ll blog the panel tonight.  Probably offer commentary on the speed geeking via twitter and follow-on posts.

Panel Format, each panelist has 8 minutes to “pitch us” as though they were visiting our organization.

Mike Feinberg, Senior VP, Cloud Infrastructure, EMC

Mike ask us to imagine: Infinite on-demand resources, economies of scale, servicing multiple industries

Commitment that is proportional to investment.  Can IT organizations deliver cloud architectures?  Is cloud synonymous with Internet access?

Customers are concerned with putting 100% of data in external cloud; customers want choice, control & flexibility, one size doesn’t fit all. 

There will be a federation of Internal & External clouds.  “internet access to capability and local access to capability”

Cloud computing is a storage and data problem.  If you are going to compute on something, need access to data and information. Refers to Atmos product.  Atmos has policy control to annotate data – confidentiality, etc.  Policy used to manage where data is stored – Atmos in datacenter vs. online.

Not a statement about internet access, but architecture.

Rajen Sheth, Senior Product Manager (and Inventor), Google Apps

3 questions he is frequently asked:

1. what applications should i move to cloud?

2. what does google offer?

3. is anyone doing this?

benefits from Google are scale, innovation, cost.

4 layers: infrastructure, platform, identity & administration, applications

calls out fallacy of just moving existing applications to the cloud and being able to take advantage of all cloud capabilities

Google started with applications: gmail, talk, calendar, docs, sites etc. 

Extended google platform to allow people to run their own applications – Google AppEngine & Web Toolkit; Gadgets; Google Secure Data Connector – secure bridge between Google cloud & enterprise, or other clouds

Value starts at Google Platform

Examples:

- Presidential Town Hall meeting, question submission, huge spike at submission deadline

- Cast Iron’s 360 degree customer view – pulled from Salesforce, Remedy

Companies that deployed apps – slide with 12-20 logos, not Fortune 500 companies

Sean Poulley, VP Online Collaboration Services, IBM

Agree with Rajen, running your infrastructure is a drag.  Slide of IBM in the cloud, working with customers on private and public clouds.

“The cloud is a new way to solve old problems”.  Problems won’t go away.  Need to protect customer’s investment. 

What is shifting to the cloud?

- workloads move to the cloud – analytics, collaboration, desktops

- cloud systems – IBM Cloud Burst – hardware, networking, systems management, virtualization for enterprises to build private cloud that has many of the capabilities of public cloud

Walking through LotusLive as intercompany collaboration platform: web conferencing, collaboration, email.  Good example for Enterprise 2.0 crowd.

Closing with IBM as trusted partner – remember, they are supposed to be pitching.

“Customer Response”

Besides the audience, the panel has two customers who will now respond to the pitches.

Q: Christopher Reichert, MIT CIO Symposium Organizer, missed name: What’s your take/response to the McKinsey study on true costs of cloud?

Mike, EMC: confusing internet access with architecture. cloud is interesting – cost savings from efficiency and late binding.

Sean, IBM: reality is not all applications will move.  Need to make economic decision, just like always.  Not just economic though, need to consider business policy, risk management trade-offs.

Doug Cornelius, Chief Compliance Officer Beacon Capital Partners – self described as “the no guy”. 

Doug’s question, “How do you deal with the geography issues” – legal, regulatory aspects of where cloud (data) is physically located.

Rajen, Google – absolutely an issue.  What will be interesting is when/how policies, law catch up with technology.  Listed a ton of policies, governmental organizations Google works with to ensure compliance.

Mike, EMC: Policy approach of Atmos allows organizations to manage this.

Sean, IBM: Tricky, technology is moving faster than the law.  Always been issues of selling/deploying technology to other countries based on U.S. policy.  Everything has cost, benefit, risk equation to be evaluated.  If you want to be ultimately safe, you would do any of this stuff, nor get out of bed in the morning.

Doug Cornelius: Records management, really talking about records destruction.  Really destroyed, not on backup tapes somewhere.  Concerned about redundancy, good for back, bad for records destruction.

Sean, IBM: No CIO in right mind would not be looking at Cloud.  Compliance though is the big concern.  This often drives private clouds.  Existing data centers are often chaotic.  There is opportunity to create “cloud environment” internally, reduce data center sprawl.

Mike, EMC: IT knows how to run datacenter, but the question is how efficient is that data center running. Opportunities for both internal efficiency and taking advantage of public capabilities.

Q: issues moving data to cloud –

General discussion that we (the industry) have been talking about this for 7-8 years, however conversation has changed, not technology issue as much as philosophical/trust issue. 

Rajen, Google mentions: security, legal contracts/data ownership, policy setting & enforcement

Q: Christopher Reichert, MIT CIO Symposium: Three bands of cloud adopters – small companies, little data to shift, large companies that have means to outsource the cloud shift (applications and data), middle group, don’t have means to shift, have critical, yet poorly performing applications.

Now I feel like I’m in vendor meeting, the question asked isn’t being answered (yet).

Rajen says good question on midmarket.  Calls out Gartner research that suggested organizations not move data when move email to cloud.  Interesting trend in midmarket is that companies just do a complete switch over.  Obviously, doesn’t work for all types of applications.

Also mentions standards based Google App Engine, development language familiarity eases adoption.

Doug Cornelius: If cloud vendor doesn’t know SAS 70, talk to someone else, if can’t negotiate terms of service, throw them out of room.  See this post of Doug’s for more tips on clouds and compliance.

@ Enterprise 2.0 Cloud Roadmaps Panel

Jake Sorofman, rPath, James Duncan, Joyent and Chet Kapoor, Sonoa Systems chat with Alistair Croll on the futures of cloud.  These companies offer software, products that are adjacent to, or run on, the cloud.  They are not cloud operators.

Jake: rPath is adjacent to cloud.  Platform to package applications for deployment and automated maintenance for many environments, inclusive of clouds.

Chet Kapoor: Visibility, Control and Scale for APIs, feeds and services.  Sonoa Systems provides technology for providers and consumers of cloud services.

James Duncan: Company had internal IaaS cloud, took that knowledge and packaged as company called Reasonably Smart, which was acquired by Joyent. 

Q: VM/AMI Standards?

Chet – standards need to move to higher level, not just VM level, but up at layer 7.

James – To predict the precise mechanism, shape or form, it’s too early.  Agrees they need to be higher level.  Standards need to reflect innovation, not run ahead.

Chet – It’s hard to get momentum around standard without real-life adoption (working code as example).  Doesn’t want to see WS* again. 

Q: Enterprises want to dip toe-in, how to do that, without being in “big cloud”.

Brings up the discussion that cloud technology is not limited to “off-premise” use.

Chet – The next 12-18 months need to resolve security concerns.  For enterprise adoption.

James – Security in the cloud is a trust issue, rather than a security issue.  Over next 12 months there will be increase in familiarity, not increase in security related products and protocols.

Q: How much of cloud computing is intrinsically linked to the client?  Organizations will want to have some code on client.

James – developers, engineers are exposed to the costs of what they are doing like never before.  That visibility will be even more granular over time.  What is the cost of any given API, or URL?  Clients will become more important in that realm.  Costs will be factor in software engineering.

Chet – RIA client to DB picture is wrong.  RIA client will fan out calls to dozens or hundreds of applications 90% of the time, only 10% will be RIA client to DB.

Will every cloud eventually be a service cloud?

Chet – comes down to one question, “is the organization comfortable sharing fate”.  What business are they in, what is their familiarity?

Jake – Companies will always want to package up the applications that contain “their secret sauce”.  These applications will never be developed on PaaS. 

Q: When all clouds are interoperable, doesn’t economy of scale win?

James – obvious comparison we try to make is to electricity.  A better commodity to compare is to is corn, pork bellies, something that needs to be moved around.  Excepting the “rot factor”.

Jake – Electricity moves more rapidly that data, but not efficiently.

Chet – Customers will self-select based on business need, application portfolio, etc.

Chet – how many enterprise CIOs actually write checks to Amazon, not many at all.  Enterprises more often use a Rackspace.

Jake – Sees use case specific cloud deployment.  Metadata enriched policies will be packaged with applications stating where that application can run.

James – Governance, Service Desk, ITIL model is concern in enterprise cloud adoption.

Q: Is data portability the new Open Source debate?

Chet – Open Source resolved accessibility problem, not “free as in beer”.  The bazaar model is far better than cathedral, offers more innovative ideas.  Customers don’t get up in the morning thinking about data portability, or getting down to 5 vendors.  Customers think about who they are betting on, and how to manage those relationships if something goes bad.  [Chet ran Glue Code prior to sale to IBM]

Management Issues

Jake – cloud will reduce barrier to application deployment.  Number of units deployed will go through the roof.  That will make the number of units to be managed go through the roof.  Tendency to deploy and forget.  This is a problem enterprises need to face.  Throwing people at the problem isn’t the solution.

One big prediction – 12 Months

James – Governance.  Governance around acquisition.  Take all those Amazon EC2 charges off of developer’s credit card expense report.

Chet – Familiarity will happen over the next 12 months.  This is as big, or bigger, than web computing.  Will see enterprise adoption.

Jake – Will see examples of high profile applications leaking to the cloud.  Will see some rogue applications, breaches happen.  Will force controls, formalized strategies, governance.

@ Enterprise 2.0: Alistair Croll on Moving to the cloud

Which cloud you go to, depends on what you are moving.  Move machines, code, processes or content.  This is the clearest way to determine what type of cloud an operator is offering, ask them “what do I move to you – machines, code, processes or content”.

Alistair is qualifying “move”, in that some code might need to tweaked for the features/functions/services of the cloud, or perhaps re-written in the case of tightly coupled legacy code.

Clouds as a utility

Nick Carr, Big Switch.  Common need set, not a differentiator, economies of scale.  When these things happen, this pattern exists, you get a utility model.

Alistair says the real question is, “is computing like electricity?”  Now referencing Chris Anderson’s to be released book, Free.  These points are consistent with Alistair’s Interop talk, which I blogged about previously.

One aspect of utility is decreasing cost.  Another is degree of elasticity. 

Computing is not like electricity, because (according to Forrester’s James Staten) no interoperability standards, and only fits loosely coupled applications (SOA). 

Other reasons from Alistair, can’t have electricity breach, electricity doesn’t have to be monitored for HIPAA compliance, electricity doesn’t lock you in (plugs, interfaces).  Electricity outages have easy back-up plan, batteries and generators.  Electricity doesn’t suffer from utility sprawl. 

Issues with cloud computing

Alistair says “cloud bursting is nonsense”.  (IBM won’t like that).  It’s all about the data.  The biggest cost is moving the data.  It’s also a time issue.  Can the data be moved quick enough to support unplanned spike?  If not, data needs to be kept synched with cloud (burst destination).  This is expensive.  Might require all data to be moved to hosted environment connected to the cloud.

Who owns the metadata?  Typically, it’s the cloud provider.  This is issue when crowd sourcing results in metadata that provides value to your business.

Too much choice right now.  A lot of people are sampling, but not a lot are buying.  Alistair implies there will be more buying when there is less choice, because industry will be settling out.

Cloud can dump you.  Cloud provider has freedom in relationship, can discontinue service even if consumers hasn’t broken terms-of-service.

Taxation issues.  State of NY wants to tax transactions done in environments hosted in NY, even if business (cloud consumer) isn’t subject to NY tax.  As a former retailer, I’d call this Nexus.

What is you are a Cloud?  Has the ship already sailed?

If you aren’t thinking in terms of shipping containers, instead of racks, you shouldn’t be considering cloud computing to compete purely on economy of scale.

Beyond shipping containers, can you build by dam, or buy nuclear power plant.

Answer, specialize.  One potential market, legal drivers that force local (geographic) data storage.  Canadian government won’t store data, use applications, in US based clouds.  (Patriot Act implications)

Others: offer different contract terms, user interface, support – more help to onboarding.  Niche markets. 

Cloud Futures – Why Clouds are Cool

Clouds are cool not for themselves, but for what flows over it.

Enterprises today think of clouds as peripherals.  Something on the edge, that you plug in.

Enterprises need to think about disruptive aspects – perform tasks couldn’t before, speed up the organization, etc.

What will matter more as computing becomes less expensive:

- data synch

- portability

- always connected

- transcoding in the cloud

- situational awareness

Alistair gives example of how cloud computing, and the ability to have split-second auctions, will be the downfall of NYC taxi medallion program in favor of “just-in-time” town car arrangements.

He says this is one example of how cloud computing will change our everyday lives. 

[I’m not convinced that it’s cloud computing that changes everything.  I think the internet, cellular, smart handhelds, constant connectedness changed everything.  The cloud is an extension of prior works.  But, not all internet applications need to be cloud resident.]

Next Cloud Watching Stop: Enterprise 2.0 in Boston, June 22, 2009

Continuing my broad survey of cloud computing, I’m dropping by Enterprise 2.0 in Boston.  The cloud computing program starts with a full day of talks and panel discussions and concludes with an Evening in the Cloud:

“…leading purveyors of cloud computing will explain how best to leverage your existing IT investments while getting the benefits of the cloud. In addition to provoking discussion, this interactive program will allow you to "invest a virtual $1 million" in the cloud-based solution(s) you believe will give your business the most bang for its buck.”

As has become a habit, I’ll share the highlights via live-blogging and tweeting.  I’m looking forward to the evening “speed-geeking”, where the vendors have 6 minutes to demo their solutions in an effort to earn a portion of our (virtual) $1 million portfolios.  Given elasticity is a fundamental tenet of the cloud, I’m wondering if there is a way to “scale-up” my portfolio.  And of course, lose the “virtual” aspect…

If ‘un-virtualizing’ that $1 million portfolio doesn’t work out, I have a plan underway that removes the “un” from my unintentional cloud watching.  More on that another time.

Grumpy Architect week: There is more to services than re-use

Perhaps I’m just grumpy this week.  Or, concerned for the future.  Or, most likely, both.  Nevertheless, I find conventional SOA lore more bothersome than usual.  Specifically, the paired notions that the sole reason to implement services (or not) is re-use potential, and that the main architectural aspect of SOA is governing said services for re-use. Now, don’t misinterpret, there is true value in sharing services and governance is critical.  However, SOA, or better said, services-architecture doesn’t begin and end with re-use potential and enforcement.

For those with architectural backgrounds – software not marketing trend – what follows is nothing new.  You are well acquainted with foundational tenets such as separation of concerns, modularity, loose coupling, cohesion etc and the associated benefits.  Unfortunately, based on my interactions over the last several months, I must report (a) this knowledge is not universal (b) people can’t articulate the benefits of well-architected software and/or (c) the dots don’t connect all the way to SOA.

Since the presence of well-defined (and well-built services) is assumed in a bevy of existing and emerging technology strategies -- mashups, event-processing, business process automation and cloud computing -- we need to correct the record on the total value of services and make the connection to proper architectural discipline.

To aid in this ‘services-architecture’ education, I’d like to call out excerpts of three works.  The first source is Luke Hohmann’s excellent 2003 book, Beyond Software Architecture.  In Chapter 1, Hohmann describes (reminds us of) architectural design principles that have stood the test of time:

“Encapsulation
The architecture is organized around separate and relatively independent pieces that hide internal implementation details from each other.

Interfaces
The ways that subsystems within a larger design interact are clearly defined.  Ideally, these interactions are specified in such a way that they can remain relatively stable over the life of the system.  One way to accomplish this is through abstractions over the concrete implementation.  Programming to the abstraction allows greater variability as implementation needs change.

…Another area in which the principle of interfaces influences system design is the careful isolation of aspects of the system that are likely to experience the greatest amount of change behind stable interfaces.

Loose Coupling
Coupling refers to the degree of interconnectedness among different pieces in a system.  In general, loosely coupled pieces are easier to understand, test, reuse, and maintain, because they can be isolated from other pieces of the system.  Loose coupling also promotes parallelism in the implementation schedule.  Note the application of the first two principles aides loose coupling.

Appropriate Granularity
One of the key challenges associated with loose coupling concerns component granularity.  By granularity I mean the level of work performed by a component.  Loosely coupled components may be easy to understand, test, reuse, and maintain in isolation, but when they are created with too fine of a granularity, creating solutions using them can be harder because you have to stitch together so many to accomplish a meaningful piece of work.  Appropriate granularity is determined by the task(s) associated with the component.

High Cohesion
Cohesion describes how closely related the activities within a single piece (component) or among a group of pieces are.  A highly cohesive component means that its elements strongly relate to each other.

Parameterization
Components can be encapsulated, but this does not mean that they perform their work without some kind of parameterization or instrumentation.  The most effective components perform an appropriate amount of work with the right number and kind of parameters that enable their user to adjust their operation. 

Deferral
Many times the development team is faced with a tough decision that cannot be made with certainty. …By deferring these decisions as long as possible the overall development team gives themselves the best chance to make a good choice.  While you can’t defer a decision forever, you can quarantine its effects by using the principles of good architectural design.” 

To state the obvious, the above principles all apply to service design.  Pointing out the (apparently) less obvious, the value of applying these principles – protecting against and planning for change, breaking up work, smart-sizing assets, isolating risk – are benefits that can be derived from services, regardless of re-use potential.

Moving to a real world example, the March 2008 Harvard Business Review featured an article by David M. Upton and Bradley R. Staats, entitled Radically Simple IT.  The article is on Japan’s Shinsei Bank implementing a new enterprise system:

“In our research, we discovered a standout among the companies applying the path-based method: Japan’s Shinsei Bank. It succeeded in developing and deploying an entirely new enterprise system in one year at a cost of $55 million: That’s one-quarter of the time and about 10% of the cost of installing a traditional packaged system. The new system not only served as a low-cost, efficient platform for running the existing business but also was flexible enough to support the company’s growth into new areas, including retail banking, consumer finance, and a joint venture to sell Indian mutual funds in Japan.

The path-based principles that Shinsei applied in designing, building, and rolling out the system—forging together, not just aligning, business and IT strategies; employing the simplest possible technology; making the system truly modular; letting the system sell itself to users; and enabling users to influence future improvements—are a model for other companies. Some of these principles are variations on old themes while others turn the conventional wisdom on its head.”

Although the entire article is excellent, I wanted to call out the section on “Modularity, not just modules”.  The emphasis is mine.

“While the prevailing view that big IT programs and systems should consist of modules is hardly new, the concept of modularity is often misunderstood. Just because a software developer claims that the various parts of its applications are modules does not mean that they are actually modular. Modularity involves clearly specifying interfaces so that development work can take place within any one module without affecting the others. Companies often miss that point when developing enterprise systems. For example, we know of an automobile company that had teams working on multiple modules of a new enterprise system and claimed to have a modular design. However, one team was in charge of interfaces and was constantly changing them. Every alteration by this group forced all the other groups to spend huge amounts of time redoing the work they had already completed. Rather than limiting the impact of changes by embracing modularity, this company had actually amplified problems!

A truly modular architecture allows designers to focus on building solutions to local problems without disturbing the global system. With small, modular pieces, the organization can purchase off-the-shelf solutions or turn to inside or outside developers for a certain piece, accelerating the speed of development. Modular architecture also makes it easier to upgrade the technology within modules once the system is up and running.

Breaking down and solving problems in this way offers a number of advantages beyond speed. It allows the IT team to concentrate on obtaining the lowest-cost solution for each part and (by partitioning work) reduces the impact of a single point of failure. Clearly specifying the functions of modules and the interfaces makes it easier to build a module that can be reused in other applications.

The modular approach was a critical part of achieving the bank’s strategy, as Dvivedi described it, “to scale up and expand into new activities with ease, to be able to service the needs of the organization as it grows from a baby into an adult…and avoid building capacity before we need it.” Take loan-processing capabilities. The project team rolled out the capabilities in small stages for three reasons: to prove to management that the computer system would perform as promised, to avoid overwhelming managers and users with too much automation all at once, and to be able to address any technical issues quickly as they arose. Accordingly, the team initially sought to show that the system could correctly approve credit for a small number of loans (20 to 30 a day). Then the team developed the capacity to fully process 200 to 300 loans a day. As the business grew, Shinsei eliminated manual work to reach a capacity for processing 6,000 loans a day.

Thanks to the modular structure of the automated system, Shinsei can simply replace one part (the loan-application or credit-checking functions, for example) without affecting the rest. What’s more, modularity has allowed Shinsei to change its IT when appropriate or necessary without having to risk upsetting customers. It can keep the customer interfaces (such as web pages or the format of the ATM screen) the same while changing the back-end systems.”

Besides the excellent real-world example in applying and benefiting from the architectural principles cited by Hohmann, this article also calls out the ability to source functionality at a modular level.  With the advent of cloud computing, and subsequent opening of service markets, there is even more motivation to design and implement a services architecture.  As Dave Linthicum advises, “leverage other people’s work”.

Lastly, I want to point out a sidebar Guide to Modularity, from a 1997 Harvard Business Review article on Managing in an Age of Modularity.  The premise of this article was to introduce managers outside of technology and manufacturing to embrace modularity practices in product development:

“By breaking up a product into subsystems, or modules, designers, producers, and users have gained enormous flexibility. Different companies can take responsibility for separate modules and be confident that a reliable product will arise from their collective efforts.”

A Guide to Modularity

“Modularity is a strategy for organizing complex products and processes efficiently. A modular system is composed of units (or modules) that are designed independently but still function as an integrated whole. Designers achieve modularity by partitioning information into visible design rules and hidden design parameters. Modularity is beneficial only if the partition is precise, unambiguous, and complete.

The visible design rules (also called visible information) are decisions that affect subsequent design decisions. Ideally, the visible design rules are established early in a design process and communicated broadly to those involved. Visible design rules fall into three categories:

•    An architecture, which specifies what modules will be part of the system and what their functions will be.

•    Interfaces that describe in detail how the modules will interact, including how they will fit together, connect, and communicate.

•    Standards for testing a module’s conformity to the design rules (can module X function in the system?) and for measuring one module’s performance relative to another (how good is module X versus module Y?).

Practitioners sometimes lump all three elements of the visible information together and call them all simply “the architecture,” “the interfaces,” or “the standards.”

The hidden design parameters (also called hidden information) are decisions that do not affect the design beyond the local module. Hidden elements can be chosen late and changed often and do not have to be communicated to anyone beyond the module design team.”

In respect to SOA, the design rule most often broken is identifying “what modules will be part of the system and what their functions will be.”  The most common mistakes:

1. the service portfolio map’s scope is immediately reduced to “those services that will be re-used”
2. the service portfolio map mirrors the current software asset repository
3. the service portfolio map is a derived artifact from individual project plans and deliverables

In creating a service portfolio map, start with business capabilities, business processes and/or business information, and perform business analysis to identify key business concepts that will represented by, further partitioned into, services.  Depending on the granularity of your starting point, work two to four levels down.  For instance, if your starting point is Supply Chain, you’ll still be doing business analysis four levels down.  If your starting point is Warehouse Receiving, by the fourth level you are probably in implementation detail.  Fine for a Warehouse Receiving project, but too deep for your service portfolio map.

With a clear understanding of the architectural aspects and full benefits of services, and a high-level service portfolio map, you can better position your organization to succeed in this new environment where services, and a services mindset, are assumed.