That's the advice of Mark Lines, partner with Scott Ambler & Associates, who argues that while scrum is a good starting point for agile in the organization, it falls apart when large teams are required, or if software development takes place in different locations across the globe.

"Scrum assumes you work in small teams, ideally collocated in one room," he pointed out in a recent interview (see video, below). "You don't have to talk to other teams in regards to architecture requirements and things. You can make all the decisions about the project yourself."

However, most agile teams don't all work in the same room, or even in the same city, for that matter. To offer new ways to address these challenges, Lines and Scott Ambler published a book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise, which surveys available alternatives to simple agile practices. Disciplined Agile Development (DAD) is a decision process framework that "brings together some of the good practices from the disparate set of methods that out there and combine it into a whole," Lines said.

"It would be nice if we were all collocated in small teams, and we didn't have to talk to anybody else, but that's not a reality," he continues. "What if you're in situations where you need to more than what a classic agile project would ask for?" Examples of software projects beyond the scope of agile include applications subject to regulatory mandates, or complex programs such as software for rocket ships or medical devices.

Teams are larger than two to nine people like scrum would prefer. There are a lot of other concerns in the enterprise, like architecture, database standards, and governance, that haven't been talked about with other methods."

"Were seeing Agile projects with 300-person teams. You cant obviously be collocated, so you have to figure out a way to make that successful and still be agile," he said. Also, you have off-shoring ... outsourcing, distributed teams, technically complex, functionally complex applications."

By applying DAD, developers pull in the best practices across a range of methodologies.

That's the prediction from Gartner analyst Alexa Bona, who chides the current state of contracts, which all too often "have ambiguous terms regarding the maintenance of data confidentiality, data integrity and recovery after a data loss incident."

Bona outlines three options enterprise cloud buyers need to exercise every time they cut a cloud agreement:

Bring in third-party verification. SaaS contracts should "allow for an annual security audit and certification by a third party, with an option to terminate the agreement in the event of a security breach if the provider fails on any material measure," Bona advises.

Insist on standardized assessments. "Ask a provider to respond to the findings of assessment tools," says Bona. "The Cloud Security Alliance (CSA), for example, has a Cloud Controls Matrix in the form of a spreadsheet containing control objectives deemed by participants in the CSA to be important for cloud computing."

Include adequate service levels for security and recovery, including recovery time objectives, recovery point objectives, and data integrity measures. “Whatever term is used to describe the specifics of the service-level agreement, IT procurement professionals expecting their data to be protected from attack, or to be restorable in case of an incident, must ensure their providers are contractually obligated to meet those expectations,” says Bona.

Along with Gartner's recommendations, there are other pro-active steps cloud consumers can take to ensure that their vendors fulfill their roles as partners:

Get involved with a user group or advisory committee associated with the vendor. This helps provide clout, as well as build personal relationships with managers on the vendor side. 

Maintain relationships with mutiple providers, including the option of going back to your own data center. Nothing delivers more favorable terms in business than competition.

More food for thought: in an issue of Stanford Technology Law Review earlier this year, researchers affiliated with the QMUL Cloud Legal Project at the University of London reported on conversations with cloud providers and consumers, identifying the major points of discussion — or contention — that have been coming up in negotiations for cloud engagements. 

Major areas of disagreement include the following, as outlioned in the article:

• Who’s liable for damages from interruptions in service? (Cloud providers won't accept liability for issues.) ,
• Number of perfromance indicators within service level agreements. (The more you pay, the more you get. Smaller customers tend to get 5-10 key performance metrics.)
• Data availability and data loss. (Many cloud porviders won't assume liability for data loss.)
• Physical location of data. (A big issue for European enterprises, since data must reside with the bounds of the EU. However, many providers are opaque about the whereabouts of data centers.)
• Vendor lock-in. (Vendors try to get long-term contracts, with onerous automatic renewal policies. But at the same time, that won't stop vendors from changing their service terms)
• Compliance data, return of data upon contract termination. (Vendors won't provide this voluntarily.)
• Intellectual property rights. (Right now, a very murky area. What happens when cloud providers make changes to data and applications?)

In the month of July, 3,600 jobs were created in data processing, hosting and related events, according to the latest Bureau of Labor Statistics report.  That’s the single best month of job growth in this category since June 1998.

While the BLS numbers don't dissect the IT jobs in terms of specialty, Dice says its own numbers show growth in the "cloud" category. As the online tech job placement service put it: "Cloud service providers report in this category and their services appear to be increasingly in demand. The number of jobs posted on Dice containing the word 'cloud' hit an all-time high in August and account for six percent of all job postings."

There has been plenty of consternation that the rise of cloud computing means trouble for IT career prospects. But so far, interest in cloud from enterprises has been helping to fuel a boom.

Dice also further parsed the BLS jobs report, noting that the unemployment rate for technology professionals fell to 3.8% in July, from 4.2% in June. For the overall workforce, the unemployment rate stood at 7.4%. Technology consulting added 4,300 positions in July and 40,300 jobs this year.

(Source: Dice.com)

That's the question posed in a recent report by Forrester analyst Stefan Ried, Ph.D., who, along with his co-authors (including SOA proponent Randy Heffner), call for a next-generation "hybrid integration" approach that federates different integration silos and topologies, regardless of where they are in relation to the enterprise. 

Bringing these worlds together is important, since it's unlikely that enterprises will tear up their on-premises investments to move to the cloud. Yet, it's also a reality that a large number of businesses rely on the cloud for at least some of their capabilities.

Forrester's survey of 1,631 enterprises shows that "only a minority of enterprises plan to replace or have already fully replaced Java and .NET runtime platforms or [business process management] and BRM with cloud platforms." The survey also finds that about one in four are interested in combining business steps located in the cloud and on premises into single processes.

The analysts provide an example of how an integrated process scenario plays out:

"A manufacturing company receives requests for quotation via a cloud-based application and answers these requests with a traditional on-premises product life-cycle management (PLM)/ERP system; the decision to offer discounts might be supported by an analytics application provided from the cloud but will seamlessly appear in the user interface of the ERP system. The boundaries between cloud and on-premises applications will increasingly blur — in the end becoming totally invisible to many business users."

So how do companies get to this hybrid environment, that treats all data and applications, no matter where they're based, equally? It takes new thinking among IT leaders. There will be no single product or solution to address this, since it is more of an architectural problem.  Here are some pointers:

• Shift from one-off integration projects to time to market.
• Bring "systems of record” (ERP, finance, control) together with “systems of engagement” (CRM, collaboration). 
• Emphasize business value, rather than IT optimization.

That's the view of Bruce Guptill, analyst with Saugatuck Research, who points out in a new paper that "everyone has been looking at SaaS (and Cloud) TCO incorrectly or incompletely." This is still an inexact science, he observes, and in almost cases he has looked at, SaaS/cloud approaches were compared "against traditional IT solutions and situations, which usually have different cost types and accounting practices." SaaS and cloud costs will vary greatly from year to year, depending on the stage if implementation.

Guptill outlines 6 key areas in which cloud or SaaS TCO can be determined, while cautioning managers from getting too hung up on the cost aspect, which may far less important than the value the solutions are bringing to the business:

• Licensing. As the number of users may grow, but will likely remain between 10 and 15 percent of the solution’s TCO, Guptill advises.
• Implementation. These costs will be greatest during the first few weeks, but then will likely disappear for long stretches of time.
• Integration. Such costs will increase 'from less than 10 percent in the first year to between 25 and 35 percent annually thereafter, at least through the first few years," says Guptill.
• User training. These costs may be higher at first, but will shrink to less than 10 percent of TCO, due to greater user familiarity and greater peer-based training.
• IT training. The costs of getting IT staff up to speed with the services accounts for between 10 and 15 percent of first-year TCO, then keeps on growing for a year or two. At that point, Guptill says, IT training costs then level out and decline "as the IT staff become familiar and comfortable with the solution in its extended/expanded environments."
• Internal support. Tne costs associated with internal support is due to the success of the cloud program itself. As the complexity of and resources required  for a cloud engagement grow, Guptill points out, internal support requirements will grow as well.

Accenture announced it is collaborating with Michelin Group to create a new business – Michelin solutions, supporting the "MICHELIN solutions brand." The new operation will deliver mobility solutions to customers through the use of the Accenture Cloud Platform and a range of solutions offered on a pay-per-use basis.

Michelin solutions' mobility-enabled applications are targeted at business customers who manage fleets of vans, trucks and earthmoving equipment, Accenture says. "These solutions will help manage areas such as fuel efficiency, tire management and vehicle productivity solutions."

In July 2013, Michelin launched its first solution, called EFFIFUEL.

(HT to CloudPro's James Stirling for surfacing this story.)

Who will be the key IT or software providers of the 2010s? Thanks to their ability to build and deploy private cloud and mobile apps, many traditionally non-IT companies are evolving into software providers in their own right.  There are now countless examples of enterprises making the leap, inclucing insurance companies, banks, and aircraft manufacturers, who see the opportunity to digitize their knowledge and expertise -- as well as monetize data center capacity -- to launch new business lines.

Vala recently spoke with Casey Coleman, the agency's CIO, to glean some of her secrets on what it takes to successfully run a forward-thinking $500-million-a-year IT operation (actually, maybe "secrets" isn't the best term, as Coleman seems to apply common-sense management to keep things moving forward at an impressive clip):

1. Go First: GSA is a provider of business and technical services to agencies within the federal government, so it makes sense to keep on top of leading-edge technologies. GSA was "the first agency to move to a cloud-based email and collaboration platform which provides significant cost savings and improvements to security, mobility and performance," Vala relates. For a huge disruptive technology such as cloud or mobile, Coleman encourages and supports employees to experiment, pilot, and innovate with the new technology. This may run counter to government corporate culture, but GSA does it.

2.  Break Down the Walls, Literally and Figuratively: GSA got rid of its walled offices, and now has collaborative workspaces in which employees "book" the spaces they need on a daily basis. Two-thirds of GSA employees now telework.

3. Technology for Business Sake (Not Technology Sake): A lesson that needs to be repeated in the private sector as well. Coleman keeps hammering this point withiin GSA. How much money does the technology save? How does it improve end user and customer satisfaction?

4. Deliver Rapidly and Frequently: GSA's IT department recognizes that many non-IT units could buy into technology solutions without IT's involvement. That's why the IT department has to be as agile as possible, working closely with users and getting solutions out the door as rapidly as possible.

5. Collaborate, Collaborate, Collaborate: Put social media to work to enhance communications.

6. Keep Things in Harmony: In Coleman's words: "I think of the CIO today as being a choreographer or a conductor of an orchestra, bringing various services together and choreographing the delivery of those services."

7. Deliver Routine Services in an Excellent Fashion: Again, Coleman's words: "You build credibility when the network is up and apps are routinely accessible and that gives you a platform to do more. It is essential to build relationships, personal trust and credibility within the business."

In their just-released book, Cloud Computing: Concepts, Technology & Architecture, authors Thomas Erl, Zaigham Mahmood and Ricardo Puttini spell out some of the key varaibles that make for a successful service level agreement for cloud services.

Quality of service is essential to meet cloud consumers' business requirements, and the following are examples Erl and his co-authors provide as ways to measure and ultimately assure this quality:

Availability Rate Metric: "Percentage of service uptime; measured as total uptime against total time"; expressed in percentages.

Outage Duration Metric: "Duration of a single outage"; measured by date and time outage began and ended, expressed in hours and minutes.

Mean-Time Between Failures (MTBF) Metric: "Expected time between consecutive service failures"; measured by normal operational period duration and number of failures; expressed as average number of days.

Reliability Rate Metric: "Percentage of successful service outcomes under pre-defined situations"; measured by total number of successful responses; expressed as percentages.

Network Capacity Metric: "Measurable characteristics of network capacity"; measured by bandwidth, throughput in bits per second; expressed as number of megabits per second.

Storage Device Capacity Metric: "Measurable characteristics of storage device capacity"; measured and expressed in storage size in gigabytes.

Server Capacity Metric: "Measurable characteristics of server capacity"; measured and expressed as number of CPUs, CPU frequency in GHz, RAM and storage size in GBs.

Web Application Capacity Metric: "Measurable characteristics of Web application capacity"; measured and expressed as requests per minute.

Instance Starting Time Metric: "Length of time required to initialize a new instance"; measured by data and time the instance was up and the date and time of the start request; expressed in minutes.

Response Time Metric: "Time required to perform synchronous operation"; measured by date and time of response and total number of requests, expressed as averages in milliseconds.

Completion Time Metric: "Time required to complete an asynchronous task"; measured by date of request to date of response and total number of requests; expressed as averages in seconds.

Storage Scalability (Horizontal) Metric: "Permissible storage device capacity changes in response to increased workloads"; measured and expressed in storage size in gigabytes.

Server Scalability (Horizontal) Metric: "Permissible server capacity changes in response to increased workloads"; measured and expressed as number of virtual servers in resource pool.

Server Scalability (Vertical) Metric: "Permissible server capacity fluctuations in response to workload fluctuations"; measured and expressed as number of CPUs, RAM size in gigabytes.

Mean-Time to Switchover (MTSO) Metric: "Time expected to complete a switch over from a service failure to a replicated instance in a different geographic area"; measured by date and time of failure and total number of failures; expressed in minutes.

Mean-Time System Recovery (MTSR) Metric: "Time expected for a resilient system to perform a complete recovery from a service failure"; measured by date and time of recovery to date and time of failure and total number of failures; expressed in minutes.

As with all things disruptive, the open-source "cloud operating system" started off enabling many under-funded organizations to start building their own clouds. Now, it has already worked its way up into Fortune 1,000 territory:

"OpenStack is maturing, it’s coming of age and new users being announced every week (Fidelity, Comcast, Best Buy, Bloomberg).Over the past three years, we’ve also seen OpenStack grow internationally. There are now over 40 global user groups and more than 10,000 community members across 121 countries. And we’ve recently crossed the 1,000 authors threshold to the code base."

Some comments from OpenStack community leaders:

Elizabeth Krumbach Joseph, automation and tools engineer at HP: "In spite of all the press that I see, I still get people asking me if OpenStack is 'actually used in production anywhere.' It’s a great opportunity for me to rattle off my list of Fortune 500 companies who use it, but it seems like the press for that hasn’t quite penetrated as far in the industry as we may like."

Clint Byrum, HP Cloud Services: "Much like Linux, I’d like to see OpenStack get to a point where it is just obvious that this is the place you go to contribute. I’d like to see OpenStack as the platform that the leaders stand on to drive innovation in the IT space."

Wayne Walls, cloud architect at Rackspace: Two compelling arguments for OpenStack: 1) "The community ecosystem is friendly, brilliant and engaging.  OpenStack is like a family, sure there are disagreements, but at the end of the day everyone is looking out for each other and wants to make OpenStack the best it can be for the world to use; and 2)  OpenStack unlocks the ability to pick the right place for your application to get the best benefit.  It’s a true hybrid cloud strategy."

Another reader, JamFuse, urged a more holistic view of the vendor lock-in cycle, which ultimately makes IT managers' jobs dull and miserable. I surfaced most of JamFuse's comment below:

"Are you all bitter because you are locked in to some off-the-shelf proprietary product that gives you no interesting implementation projects, no job satisfaction, and yet still does not solve your problems?" the reader asked.

As JamFuse explained it, cloud may offer a way to get around all of this staleness:

There is a potentially a better chance to avoid vendor lock in with cloud products than there has been for many other infrastructure-based products. There are two reasons for this, and both revolve around understanding the level of abstraction in the architecture:

1. Abstraction from the cloud infrastructure vendor: "Both OpenStack and full-blown vCloud are being implemented by multiple infrastructure vendors. They may have slight quirks in implementation, but if you read the labels carefully, you should be able to move between infrastructure vendors of your chosen cloud ecosystem. Or between public and private. This sounds similar to a where you could have only two or three big eco-system players which comes close to the argument that lock-in is unavoidable except the infrastructure vendors would be offering different support packages underneath the ecosystem from fully managed 24/7 phone to no-support-diy. This will then create some choices and avoid complete lock-in."

2. Abstraction from the ecosystem: "This is where it gets more complicated, but truth is that if you do the hard work at the beginning, you will have flexibility later on. You need to get into the 'infrastructure-as-code' mentality in a big way. Get familiar with a configuration management tool like Puppet/Chef/Ansible/Salt, and write descriptions for each piece of infrastructure. The annoying bit is then having to find the right orchestrator and bootstrap tools for the ecosystems, but once done, you can affectively move between ecosystems, as a migration, as a burst, or even as failover or load balancing between datacenters."

The bottom line, JamFuse said, is pursuing this architectural approach to cloud "means actually understanding it and getting people involved to set it up properly, not just paying for the latest platform/model/product and expecting it to work perfectly for any given scenario ... If you go down this road, you could make some big wins now and give yourself an infrastructure which can move around and so save company money in the future. Plus, you might get more interesting projects to do, more job satisfaction, and generally be a bit happier!"

Well said.

Those are the lessons learned by Twitter's development team, as recently explained by Jeremy Cloud, leader of the vendor's Tweet service team, at the recent QConNY conference. The challenge to providing failure-resistant services that support more than 400 million messages a day is to allow for failure, he says.

Cloud's top three takeways consist of the following:

1. In order to make big changes, make very small changes. "If you want to make a really big change, you can increase your chance of success by making many small changes," says Cloud. "A couple of times at Twitter, we tried to do something big where we put our heads down for six months, to build something really big and bring it up at the end. But invariably, these things fail -- things change on the ground during that time."

The key to success, Cloud says, is to "1) make the smallest possible change you can make; 2) verify that it works; and 3) repeat. Do it over and over. With each step, you’re making course corrections, and you can minimize the risk at each step."

The key, Cloud says, is to deploy often and deploy incrementally. "When we develop a new feature, the first thing we do is deploy the build with the feature off. Then we turn the feature on to maybe 1%. The same thing applies to how we do a new service. We try to find the smallest thing you can break off to start with, code that up and slowly turn traffic up to it."

2. Integration testing is very hard.  Testing for all possible scenarios with multiple services is one of the most difficult pieces of SOA, Cloud admits. "Planning your integration test and strategy is very hard.  We’ve learned, unfortunately the hard way, that integration on SOA is actually really hard."

Cloud considers integration testing an area that his team still hasn't been able to fully address to its satisfaction. "This is largely an unsolved problem that we have at Twitter, it's a manual and tedious problem," he says, pointing out that with single, monothic applications, testing could be conducted with one button.

In SOA, "when you have dozens of services that all have to work together, it presents a pretty complex picture. The hard problem in SOA is testing services that span multiple servers. You need to launch all of those services with the change. The services need to effectively point them all at each other. The services may have downstream dependencies."  The only way to address this is to think about integration testing as early in the process as possible, Cloud concludes.

3. Failure is always an option. With SOA, "you're still going to have a lot of unsolved problems," Cloud says. "A single request could turn into thousands of [remote procedure calls]...  and every RPC call is a chance for failure." The best approach is to be able to "degrade gracefully," says Cloud. "You want to make sure you want your system to degrade as quickly as possible.  Avoid single points of failure. You to make sure than if any one node in your system goes down, that’s no problem.  You want to make sure you have plenty of redundancy in your system, and have a fallback strategy. If things start going bad, what are you going to do? If you lose 25% of your cluster."

Actually, a full-blown failure isn't the challenge -- it's the much more common partial failures that are difficult to manage. "It turns out that most of the problems you’ll most encounter are not full failures, but partial failures," he says. "They’re much harder to imagine -- the number of ways something can fail is mind-boggling." He recommends executing a new service or function in production, and purposely "unplugging an entire rack if you’re running  your own data center.  If reliability matters -- and it should -- you really need to spend most of your development time thinking about failure cases -- implementing failure scenarios and actually testing them in production."

(A full video of Jeremy Cloud's presentation, "Decomposing Twitter: Adventures in Service Oriented Architecture," is available at the InfoQ site.)

There are ways enterprises, as well as the industry in general, can address these lock-in issues. Solutions to potential vendor lock-in were recently surfaced in a new guide from The Open Group.

The guide, compiled by a team led by Kapil Bakshi and Mark Skilton, provides key pointers for enterprises seeking to develop independently functioning clouds, as well as recommendations to the industry on standards that need to be adopted or extended.

Here are 10 key problems and recommendations identified by The Open Group team for achieving cloud formations based on standards, rather than on vendor technology:

Platform-platform interfaces:  A universally used standard for platform-platform interfaces — the Internet, HTTP and message envelope layers of web service APIs — "would provide a major part of the basis for real cloud interoperability," the guide states.  The two styles of web service interface handled by platforms — WS-I and raw HTTP — each has strengths for specific applications. "Many small-scale integrations that originally used WS-I with SOAP and XML, because JSON was not mature enough at the time, are now moving towards raw HTTP and JavaScript Object Notation because it is better suited to their needs. However, for enterprise-level integrations, SOAP is still king."

Recommendations:

• Use WS-I as the service platform interoperability interface between cloud services.
• Use direct HTTP with JSON as the service platform interoperability interface.
• "The industry should identify best practice in use of direct HTTP and JSON, including means of authentication and access control (such as OAuth), and develop standard profiles for interoperability between service platforms using this approach."

Application-platform interfaces: "Currently, there are a number of programming languages that might be used for the interface; there is no agreement on what functionality is needed; there are no commonly-accepted application-platform interface standards that cover the full range of functionality; however, it might be agreed. There are, however, products, both commercial and open source, that implement parts of the functionality, such as Enterprise Service Buses (ESBs), and some vendor-independent interface standards for part of the functionality, such as the Java Message Service (JMS)."

Recommendations:

• "Enterprises should seek to use cloud platforms with vendor-independent programming interfaces."
• "PaaS vendors stating that they support .NET or J2EE should say which versions they support."
• "A language-independent specification of a standard cloud application platform interface should be defined."
• "Instantiations of this should then be developed for the most widely-used programming languages."

Service descriptions: The accepted standard for service descriptions, the Web Service Description Language (WSDL), has limitations, the guide says: "Its descriptions are machine-readable rather than human-friendly; it describes the functional characteristics of services, but does not cover non-functional characteristics such as quality of service and conditions of contract; it has no real ability to describe service data models; and it applies to services that use the WS-I approach, but not to services that use the direct HTTP approach." Bodies working to develop standards for service descriptions that address some of these limitations include the Web Application Description Language (WADL) authors, the Open Data Center Alliance (ODCA), the SLA@SOI Consortium, and the OASIS TOSCA Technical Committee.

Recommendations:

• "Produce clear human-readable descriptions of them, covering functional and non-functional characteristics."
• "Enterprises developing services using the WS-I approach should also produce WSDL descriptions of them."
• "Insist on the availability of clear and stable human-readable descriptions and, for services using the WS-I approach, of WSDL descriptions."
• "The industry should work to establish best practice for human-readable service descriptions covering all service characteristics, building on the work of bodies currently active in this area."
• "The industry should work to establish standards for machine-readable service descriptions, including templates and component schemas."
• "These standards should cover all service characteristics and parallel the human-readable descriptions. They should include or be linked to descriptions of service data models, and be applicable to services that use the direct HTTP approach as well as to those that use the WS-I approach. WSDL forms a good starting point for such standards."

Service management interfaces: "Standardization of these interfaces will enable the development of cloud management systems as commercial off-the-shelf products," according to the guide." Initiatives alreday underway include the "DMTF Cloud Infrastructure Management Interface (CIMI) and Virtualization Management (VMAN) standards, the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA), the Open Grid Forum Open Cloud Computing Interface (OCCI), and the SNIA Cloud Data Management Interface (CDMI). The Openstack APIs may also provide de facto standards."

Recommendations:

• Ensure that "management interfaces follow emerging standards where possible."
• Look for services "whose management interfaces follow emerging standards."
• The industry should support the ongoing cloud management standardization work, including the work in the DMTF, OASIS, OGF, and SNIA, and the Openstack open source initiative."

Data models: "These do not cover the new 'NoSQL' paradigms that are increasingly being used in cloud computing," the guide states. "Also, the schema standards do not enable correspondences between different data models to be established, and this is crucial for interoperability. The semantic web standards and the Universal Data Element Framework (UDEF) can be used to define correspondence between data models, but their application is not widely understood, and they are little used."

Recommendations:

• Describe data models clearly, "using text and applicable schema standards. The descriptions should be computer-readable and have good human-readable documentation. A well documented XML schema would achieve this, for example, but just using XML probably would not."
• Look for clear data model descriptions.
• "The industry should establish best practice to describe correspondences between data models, should ensure that the standards in this area are fit for purpose, and should work to improve understanding of them."

Loose coupling: "Tightly-coupled components are difficult and expensive to integrate, particularly over the lifetime of a system that undergoes change (as most do)."

Recommendations:

• "Cloud application components should be loosely coupled with the application components that interact with them."

Service orientation: "Cloud offerings are packaged as services (IaaS, PaaS, SaaS). Cloud platform-platform interfaces, whether in the WS-I or raw HTTP style, assume client-server interaction. Service orientation encompasses and reinforces other principles – loose coupling, service descriptions, and described interfaces."

Recommendation:

• "Cloud applications should be service-oriented."

Marketplaces: "Use of marketplaces and app stores is growing, but there are as yet no standards or established good practice for their operation," according to the guide. "This means that product vendors must cater for the different requirements and practices of all the marketplaces in which their products appear, that customers must understand the different features of all the marketplaces that they use, and that marketplace operators are spending effort on unnecessary differentiation."

Recommendation:

• "Industry bodies should seek to identify the best practices for marketplace operation, with a view to defining standards and working with governments on any legislation that may be needed to underpin them."

Representational State Transfer (REST): "There is a need for robust and scalable services that are loosely-coupled and have stable interfaces that are easy to describe."

Recommendation:

• "Applications should be designed using the Representational State Transfer (REST) style, though without insisting on its full rigor."

Machine image formats: "The ability to load a machine image containing an application together with its application platform onto different cloud infrastructure services is a new form of portability that is made possible by cloud computing. A standard machine image format makes portability possible across different infrastructure service providers, as well as across infrastructure services of a single provider.

Recommendations:

• "The Open Virtualization Format (DMTF OVF) standard is designed to meet the need for a machine image format standard."
• Evaluate the OVF standard "and support it if feasible."

That means extraordinary, extraordinary attention needs to be paid to resiliency. Ben Christensen, senior software engineer for the API Platform at Netflix pointed out: "unmitigated system failures can impact the user experience, a product's image, and a company's brand and, potentially, revenue."

In a new post at O'Reilly Programming, Christensen said failure is not an option for Netflix's SOA-based infrastructure. The key, he said, is to isolate failures or hiccups within application instances. A tool the company has built to accomplish this is Hystrix, which focuses on failure isolation and graceful degradation. "It evolved from a series of production incidents involving saturated connection and/or thread pools, cascading failures, and misconfigurations of pools, queues, timeouts, and other such 'minor mistakes' that led to major user impact," he said.

The problem statement on the Histrix site puts it bluntly:

Applications in complex distributed architectures have dozens of dependencies, each of which will inevitably fail at some point. If not isolated from these external failures, the host application is at risk of being taken down with them. For example, running an application that depends on 30 services that each have 99.99 percent uptime we get ... 3 million failures out of every 1 billion requests, or more than two hours of downtime per month, even if all dependencies have excellent uptime ... Reality is generally worse.

To address requirements for uptime across all services, Christensen said his team employs Histrix to accomplish the following:

• "Isolate client network interaction using the bulkhead and circuit breaker patterns."

• "Fallback and degrade gracefully when possible."

• "Fail fast when fallbacks aren't available and rapidly recover."

• "Monitor, alert, and push configuration changes with low latency (seconds)."

Netflix's resilience challenge comes from the need to monitor and support a range of client types and interactions.

One of the beauties of a service oriented architecture, if designed well, is loose coupling -- an IT infrastructure and applications are deployed as independent components. If one element or service fails or is changed, other components in the service chain are unaffected.

That's the prediction of Joel Dobbs, CEO and president of The Compass Talent Management Group LLC, who pointed out in a recent post at the HP blogsite that CIOs are part of the "creation of a game-changing technology that reshaped or substantially altered their company's business and, in almost every case, the technology focused on directly impacting the organization's end customers."

More than being tech leaders, CIOs have to conceive and sell ideas, identify and secure resources, and be leaders: Marshaling and leading a team to create a new product or service "and successfully introduce it into the organization and the marketplace", Dobbs added.

That sounds like the role of entrepreneur.

Along with Dobbs' observations, it's notable that with the rise of cloud computing, IT organizations are either brokering or competing with outside services, or even becoming cloud providers themselves to given markets.

For anyone who wants to become a CIO at some point in his or her career over the next few years, Dobbs provided some of the prerequisites needed:

1. Vision: "An entrepreneurial visionary sees not a new task, technique, or technology, but a totally different way of doing business. Yes, this is likely enabled by technology, but the technology is simply an enabler. The vision encompasses more than projects; it involves disruptive and transformational change."

2. Passion: "When I speak with entrepreneurs, their eyes light up, their speech quickens, and they become much more animated as they explain their idea or the mission of their new company. Entrepreneurial CIOs are passionate about the mission of their company and the value their products and services provide. This passion is channeled into making the company better, not just improving its efficiency. Their passion is not just to make the IT function better, it is to make the whole enterprise better."

3. Confidence: Entrepreneurs need the self-confidence to see ideas through even when others are saying "no". Confident CIOs "are self-aware and are equally comfortable giving advice and counsel and taking initiative in areas of strength", said Dobbs. "They are also comfortable seeking advice and input from a variety of others. Confident CIOs have no problem accepting responsibility and being held accountable for their actions."

4. Comfort with ambiguity: This is also one of the tests of a successful entrepreneur, said Dobbs. "New ventures are inherently messy and uncertain, especially in the early stages. Entrepreneurs know this, learn to get comfortable with it, and lead themselves and their organizations through it. IT folks have a natural tendency to be inflexible. IT folks like 'process'. They like standards and detailed project plans. They like predictability. CIOs need to learn to deal with this uncertainty and learn to lead their organizations through periods of ambiguity."

5. Risk tolerance: "Risk is a constant companion for the entrepreneur," said Dobbs. "One of the complaints most frequently leveled at IT organizations is their aversion to risk. Entrepreneurial CIOs understand that risk is a part of the job."

6. Creativity: "Entrepreneurs find creative ways to solve difficult problems or create products that allow people to do things they couldn't do before or enable them to do them in radically different ways. Entrepreneurial CIOs are creative. They transcend traditional ideas, and traditional ideas about the CIO role itself. They truly think, and act, 'outside of the box' and create organizations that do the same."

7. Self-motivation: Successful entrepreneurs relish the "chance to do something that could change the world, or change people's lives. An entrepreneurial CIO has this same drive to do something big and meaningful, and this drive gives them the energy to push ahead when others lose focus and give up."

8. Energy, restlessness, and persistence: "Most of the successful entrepreneurs I know are never satisfied. They always believe they can do better. They "persevere through hardships, around obstacles, and over setbacks. They don't give up without a fight. Entrepreneurial CIOs must be persistent, because all of the easy stuff has already been done. The game-changing stuff is difficult, and only people who persevere through challenges succeed at difficult things."

In an effort to open up better lines of communications between development teams and managers, Avtar Ram Singh gathered a list of the major grievances developers have about their management. He titled his piece, published at the Circus Social site, "10 Reasons Why Your Programmers May Kill You" -- which suggests the tone of the responses he got.

The tone of his list of grievances may seem cranky, and may set back the collaborative utopia that agile programming is supposed to bring to enterprises by several decades. But the customer -- in this case, the internal customer -- is always right, right?  And everyone needs to blow off steam now and then, right? And the squeeky wheel gets the grease, right?

So, business-side managers take heed. Here is Avtar's list of the major grievances.

1. “Just tell me exactly what you want, dammit. None of this creative crap.”

2. “It would help if my manager understood the difference between an event and an action.”

3. “Given that I’m adding such value to your business, you might as well ask me every now and then for some input! I have some good ideas!”

4. “There’s no such thing as a simple modification. If you ask a builder to add a window to an already completed wall, he might use your head to knock out the bricks to make space for it.”

5. “I have a style of programming, and there’s no such thing as ‘churning out code’, alright? I craft my code, I’m an artist of instructions.”

6. “Maybe he should show his face during developer meetings to understand what we’re doing.”

7. “You want the status report or you want the application finished? Make up your mind.”

8. “So all that needs to be done is move this box here and that box there is it? Well why don’t you do it?”

9. “I never said that this needs to be done in four days, you did. There’s a difference.”

10. “The client is using software that was made before I was born. I don’t make you write with a feather pen do I?”

The folks at Axway just shared the results of a poll which finds at least half of enterprises are making use of application programming interfaces, 40 percent of respondents using a mixture of open and enterprise APIs, and three percent using Open APIs.

The poll was taken during a webcast, suggesting a lot of self-selection bias. But the way APIs are being used point to high levels of internal adoption. APIs are no longer just about connecting to outside web services; they are an enterprise service delivery strategy as well.

The Axway poll found that 30 percent of respondents are using APIs to expose on-premise apps to third parties. A similar number, 29 percent, use APIs to build new mobile applications, and 22 percent leverage APIs to connect internal applications to cloud services.

Forrester analyst Jeff Hammond participated in the Axway webcast, observing that APIs are the latest variation of "facade" patterns, meant to present interfaces to back-end code.  "The facade re-expressed as an API layer is going to be one of the fundamental patterns that we see emerge as we move toward modern applications," he says, noting that this is a pattern already employed by companies such as Evernote, NetFlix and TripIt. An API facade pattern "provides well-defined end-points that multiple clients can access."

The value of these patterns is found in the "very loose coupling between the client and the infrastructure side," Hammond continues. "That allows somebody like Netflix to build a Silverlight client for one device and an HTML client for another device, depending on the capabilities that are available on the client, and have these pieces independently move from the evolution of the infrastructure on the back end.:

Such an API facade pattern "using XML or JSON as the payload for RESTful web services is extremely friendly to all these mobile devices. It's kind of table stakes that you support a full HTML client on whatever client-side device you're creating today. Because of that it allows us to attack and access a lot of platforms that maybe we couldn't through traditional web services or SOAP-based protocols. Beneath this API facade pattern there's a layer of cloud-enabled elasticity that we ramp up or ramp down."

In the near future, Hammond says, "we think that almost every enterprise will have an API channel to its digital platform -- headless access to its data and business processes if you will."

That's the view of Bill Kleyman, a virtualization and cloud solutions architect, who sees robotics as the inevitable approach to managing and maintaining increasingly complex data centers. In a recent post, he says today's sites are quickly evolving into "the data center of everything," accommodating increasing numbers of users, devices, cloud arrangements, and a lot more data.

Data center automation is now commonplace, and it's only a matter of time before we start seeing robots being employed to do more physical tasks, such as retrieving and replacing servers, blades, or even entire racks, Kleyman says.

Autoloaders for tape libraries have been in existance for quite some time, enabling more rapid access to backup tapes stored away somewhere. It isn't too far of a stretch to pick up on Kleyman's scenario to imagine such robotic functions being applied to servers as well as storage systems.

Kleyman does caution that "server hardware isn't quite ready to be handled by robotics," and the hardware has to be customized. Plus, many data centers still rely on cables, and it's hard to imagine a robot being able to thread and connect cables beneath raised floors or in ceilings. The rise of wireless connectivity could alleviate some of that.

And, there's that classic showstopper for allt hings IT -- cost and ROI. Will purchasing and installing data center robots prove to be of value to the business, or does it merely optimize IT?

Indeed. That's the view of Annrai O'Toole, chief technology officer, Europe, at Workday, who explains in a new post how his company is delivering cloud services from a single in-memory environment, which are thus unencumbered by the latency issues associated with pulling data and applications from multiple servers and storage devices.

Many enterprises and vendors have integrated architectures, based on "running many different servers and databases alongside some middleware that ties the whole thing together." For example, O'Toole continues, "an ERP system implemented on-premise for an enterprise may have 20 to 30 separate servers and databases" -- requiring staffing. "Keeping 20 or 30 complex servers on the same patch version of different OSes and databases is a task involving a small army of IT professionals. This is the opposite of the current anti-fragile thinking."

Workday's approach, on the other hand, is to run all services from a single, in-memory version of the entire application logic and data, O'Toole explains. This is still built on servers that perform individual tasks, but pertinent applications and information all run within memory, free of disks. The result is a "unified customer experience," O'Toole relates.

As a result, services run faster, and "analytics operate on the live data, not a batch uploaded, out-of-date version. There is just one unified security model."

Will other cloud vendors and enterprises themselves follow suit?

O'Toole knows something about architecture. He was co-founder of Cape Clear, a web services integration vendor, which was acquired by Workday in 2008.

Design thinking is certainly behind the mobile app model, and the resulting interfaces are clean and consistent across all apps in the Apple and Android app stores.

Why not apply design thinking to internal enterprise services? In his latest post, Hilton Menezes urges that more design thinking be incorporated into service creation and deployment.

For enterprise services and apps, the result will be more highly satisfied and engaged users. Hilton proposes that service design teams, consisting of "professionals with experience in business analysis, process design and information technology,"

The service design process should include the following five steps, he says:

1. Understand your customers:  "For example, in a service to support decision making, it is essential to know the indicators and where data are, and understand the process, the dynamics and frequency that are required in a process of decision making," Hilton says.
2. Draw the service: Visualization is important. Apply visual drawings, diagrams and storytelling to vividly illsutrate what the service will deliver.
3. Prototype the service: Show how the service will flow through wireframes, videos and diagrams.
4. Design the project: Map out all the elements that the service will support, including processes, people and technology.
5. Deploy the service.

At his LessAccounting blogsite, Steven Bristol reflects on the challenges of service-orienting complex systems, noting that many such efforts in recent years have made very complex systems even more complex.  His reasoning:

"The reason SOA goes badly so often is the same reason that architecting a large project, and implementing the architecture without real world goes bad so often, and is the same reason that estimating projects so often leads to missed deadlines and budgets: while it’s relatively easy to see the forest through the trees, it’s almost impossible to see the forest, the trees, the leaves, the dirt, the twigs, the mountain side, and the people that will be driving or hiking through forest all at the same time. Seeing that level of detail, breadth, and depth requires the same clarity, insight, and wisdom that’s required to properly architect SOA or correctly estimate a project."

Agreed, it's very difficult to design services that anticipate who will ultimately be using them and how they will be used -- especially in large organizations that may look entirely different a year from now with different lines of reporting and new lines of business (and perhaps a merger or two thrown in).

The ultimately successful service oriented architecture is not designed with rigid constructs, susceptible to miscalculations at the beginning of projects, or to changes in underlying technologies as time goes on. Rather, SOA is built to allow for maximum flexibility and change. That's what the "A" in SOA is all about -- it's an architectural approach that accounts for the inevitability that projects and technologies will inevitably shift course.