One of the most significant changes in the IT landscape is the emergence of a phenomenon known as the Consumerization of IT. The explosion of personal computing devices and the rise of applications in everyday lives have fundamentally changed technology expectations.

Users expect:

• Software to conform to their way of thinking.
• Change to be rapid.
• To be able to contribute, share, and respond to the way software behaves.

This new standard of software has come about because of the rapid innovation in consumer devices such as smartphones and tablets, as well as the explosion of disruptive software services and products made possible by the internet.

Despite this revolution in the way software is perceived, enterprise IT has so far remained unchanged in the way it supplies, develops, and supports software to business users. Lead times are long, change is slow, and users rarely have significant input into new software initiatives. While this approach has been successful over the last 30 years in building the infrastructure upon which some of the greatest companies in the world rely, new strategies are needed for the new connected world.

A new era is starting when the ability to engage users and respond quickly is becoming the most important means of fostering innovation within an organization. An organization that provides strong support for this kind of user-led innovation will be able to adapt quickly to market conditions, add efficiency to existing processes, and differentiate themselves from their competitors.

Users are one of the most valuable sources of powerful new ideas; if IT doesn't have a way to harness that creativity, those users no longer hesitate to go elsewhere.

New development processes, new tools, and new thinking are long overdue to meet this need. This article describes how to re-imagine the development process under these new conditions and provide a real-world system as an example of one realization of these changes.

First, let's define some terms.

What does this mean to IT professionals?

For developers, administrators, and systems designers and planners, I'll start by defining some phrases useful to understanding a user-centric, collaborative, virtual approach to cloud application development:

• Mobile computing application development.
• The differences between user-centric and data-centric app development.
• The differences between collaborative and traditional app development.
• How virtual development and deployment functions.

Application development for mobile computing

For the purposes of this article, mobile computing refers to the ability to access applications and other software services from any location. This might be from a browser on any Internet-accessible machine or from a mobile device such as a smartphone or tablet.

The key takeaway concept is that the application is developed without any assumption about the location from which the users will access it.

User-centric vs. data-centric app development

User-centric application development takes the experience of the user as the primary concern. This includes the visual nature of the application, the flow through an application, the way in which the user interacts with the application, and the way it responds. It's both the user interface and the process flows that the user goes through. A key aspect is that data structure must not be required to realize this experience.

This user-focussed development is most effectively carried out by developers who enjoy the user engagement and feedback cycle and who thrive on satisfying and delighting real users with solutions to real-world problems.

In contrast, data-centric application development treats the data model as the first-order concern. Database schemas or other models become the primary concern and the application behavior is described in terms of data retrieval and modification. Data consistency, access controls, and service definitions are some of the critical aspects of a data-centric view of an application. Implementation work might also involve redundancy architecture and transactional design.

This aspect of an application's development is most effectively handled by developers with strong technical skills in architecting fault-tolerant transactional systems and the mechanisms by which these systems interoperate within an enterprise IT landscape.

In an adaptive organization, one able to rapidly evolve to meet critical challenges and opportunities, the two parts of an application must evolve independently. There might be multiple user-centric applications that all draw on a single data-centric system yet provide completely different experiences to the user or community of users. A user-centric application may also make use of multiple data-centric systems, such as accessing organization-wide data through shared services.

A user centric systems strategy will not only provide users with the quality and versatility of experience they demand in personal and social computing, it considerably enhances the efficacy of data-centric systems, policies, and practices — good use encourages good upkeep.

Collaborative vs. traditional app development

Traditional application development follows the specification-implementation cycle: Requirements are documented, reviewed, and approved before development begins. Requirements might take the form of written documentation, drawings, or flow charts, and the development process seeks to turn these requirements into functioning artifacts.

Socially collaborative application development provides as many users access to the application design as early as possible. The genesis of an application always lies in a business innovation: Socially collaborative application development provides tools to foster business innovation that grows seamlessly into application development to automate that great idea.

The biggest change in thinking that comes with moving to social collaboration is the need to move away from the standard "idea and requirements" elicitation process (often done in documents) to a meta-data driven architecture. This architecture needs to be free of leaky abstraction and needs to be unrestrictive in terms of what can be created. When done correctly, this meta-data structure can then completely serve the function of requirements and the experience parts of the application (where engineering detail is the focus of the development cycle). This supports the principle that business people often espouse: "Engineering aspects are easy to define but hard to implement; experience aspects are hard to define even though they are relatively easy to implement."

Rather than a single resource maintaining a central requirements document, the ideas, inspirations, and visualizations of a new application are constantly shared between users for direct input, feedback, modifications, or further ideas. Teams think in abstract, complex ways when developing broadbrush ideas: Bouncing concepts off each other to put up, test, and evolve thinking.

An efficient team thinking process is neither linear nor overly structured in its early stages. In socially collaborative application development, everything is therefore also visual, intuitive, and accessible continuously in the early stages. It seeks to provide the ability to experience the innovation as it evolves into an application as the most important step in determining its needs and provides the ability to modify and improve the application in real time.

Virtual development and deployment

Virtual application development describes the ability to create virtual development environments on demand. When development capability is required, a virtual development system can be provisioned and brought online in a matter of minutes to provide the capability to record ideas and to build applications.

Since these applications were created and developed on virtual platforms, they can be moved between the platforms freely. An application that passes a viability or ROI test might be deployed to a more public platform for further scrutiny and development effort.

This is a given made possible by cloud, although it is also available in a traditional environment.

Back to top

A vision of a user-centric development environment

In a user-centric view of application development, the ideas and input of the users are the most important parts of application design: The development environment must therefore provide the means for ideas to be recorded.

The cloud nature of this environment means that it is available from anywhere that has browser access. When an idea is to be captured, the user can simply load the environment in their browser and begin to capture content.

As these ideas become refined, they will begin to describe the concrete nature of the application that realized them, such as the screens or processes that it would contain. A user-centric development environment would therefore allow the user to turn their ideas directly into an executing application, following the structure that they have described.

Rather than transcribing ideas in a document to be implemented by some other system, a truly user-centric development process will both create the application that has been described and connect the application artifacts with the ideas and requirements related to it. This allows a user to instantly see the impact of the ideas that have been propagated; the feedback loop becomes instantaneous making it a faster process to refine and improve ideas as the realized application is evaluated.

If a development environment is truly user-centric, then it allows applications to be built and experienced without requiring any data-centric components to exist. This requires a shift in application architecture that means that the user experience can be fully realized without needing the data systems to exist yet — instead, sample or generated data is used to provide the experience. Current vertical architectures, while separating presentation from persistence, do not truly isolate the experience description from the data description because the presentation layer remains coupled to the underlying data model. The cloud and web allow you to move away from these largely vertical architectures to completely horizontal architectures where adaptability and a considerable reduction in unnecessary complexity can be obtained.

The benefits of adaptive software creation

This approach yields multiple benefits:

• To the user, change can be rapid as changes do not need to be propagated through to a data store. This lets a user to be unconstrained in his ideas and expectations.
• It also means that when the experience is complete, you have a very mature, living, fully functioning embodiment of a consumer of the required data-centric components services. Rather than cycling between requirements and prototypes (where each is constantly updated to reflect the other), you have a single place where the requirements are known in a complete, functioning demonstration of the system.

Going forward, it is inevitable there won't be a single application for a group of users; rather there will be multiple user-centric applications built on a common data-centric layer in which each application specifically serves a group of users focusing on a customized experience (allowing them to be more productive).

This will be a small step; an identical experience and motivation that has created the prevalent mobile, personal computing phenomenon of there being "an app for that," readily available for every need. Users will exploit an array of user apps highly specific to their roles and preferred way of working.

But this ability will only be possible with a state-of-the-art software development paradigm that allows a greater level of productivity and flexibility than is currently imaginable. Or is it?

Three key phases of adaptive software creation

I see three key phases of adaptive software creation:

1. Think — the genesis of ideas and needs.
2. Link — joins the concept with the larger team that can make the components happen.
3. Ink — everything becomes permanent through work to build artifacts.

Think: The genesis of ideas and business needs; completes with scope

The think phase is part of conception; it's where the business gathers and groups ideas. It's key that the capture phase can allow users to socially collaborate in an unconstrained way, with or without help from an IT professional, but usually with a team-designated analyst. This phase ends when the analyst is gradually moved from being the facilitator and discussion moderator to the fore, to ensure there is sufficient detail for scoping the conception phase. Then a scope document is created to allow a business case to be put together for the next phase.

Link: Fleshes out and links up the team conceived solution with little engineering and no translation or deletion

This phase is complete when the users (who are still intimately and interactively involved) agree that for the most part, the conception phase is complete. The project has usually also had an engineering assurance review carried out.

The link phase is mostly managed by the analyst in close collaboration with the key users. It expands on the think phase until every aspect is fleshed out to the satisfaction of the business. This means it is "experientially" complete even though the actual engineering pieces may look like they only describe how the system will work once they are implemented; in fact, the user-experience-related working logic is complete and constitutes the largely formed body of the finished application.

This is a key concept when building user-centric applications. By this point, the project is well conceived, tested, and understood.

Throughout these conception phases, the user community should be able to continually, contextually interact with, annotate, and redefine the living, evolving application, continuing the high touch principle of socially collaborative computing. This phase completes when:

• The business has walked through the whole system as often as it likes at its own convenience and confirms if this is what it wants to build.
• An engineering assurance review has been completed to identify any engineering issues (such as performance). At points where the engineering review identifies issues that will affect the experience, then the user will be taken through these and given choices.
• In the case where the project involves existing enterprise assets, then this is also the time to offer alternative solutions to the business. The key difference is that rather than saying something cannot be done, engineering is able to offer its best compromise along with the business benefits (often time and cost) of their recommended solution.

Ink: When everything becomes permanent by constructing and assembling artifacts

This phase is completed with sign-off of the fully working, deployment-ready, user-centric application.

This phase involves completing the software development work; building the components that are described and are in the working virtual application up to this stage. Of course, the tools used are designed to exploit everything about the user-centric socially collaborative process — to quickly and economically fill any gaps of complex logic and facilitate integration into existing data-centric applications.

The existing body of the application makes this stage extremely straightforward and, of course, the user community can view and test run the near complete project at will.

At the end of this stage, the user should see no difference to what they saw at the end of conception.

Back to top

A vision of a collaborative development environment

A socially collaborative development environment makes it simple for new ideas and developments to be shared between different stakeholders and technical contributors. Right from the moment that ideas and structure are captured, the intuitive, visual, browser-based nature of the cloud application development environment allows any permitted user to access, evaluate, and contribute to those ideas.

As the executing application takes shape, it can be accessed and experienced by anyone, providing an instant means to get approval and feedback as it evolves. Instead of requiring applications to be deployed to provide test feedback, a truly socially collaborative cloud environment is always available, and constantly able to be updated.

Even technical aspects of the application benefit from the collaborative, cloud nature. All the tools for application development are accessible through the cloud, so technical resources can contribute from any region and time zone with little opportunity for misunderstanding or risk of being lost in translation. Parts of application development might be allocated to remote resources, technical reviews could be performed, and remote assistance is attractive, all because of the cloud nature of the environment.

Having a common application development environment assists greatly in long-distance collaboration and support. Developers, subject matter experts, and business and industry specialists have the ability to work from anywhere at any time enabling collaborative teams that span continents.

Back to top

A vision of a virtual development environment

Developers spend considerably more time dealing with accidental complexity than they do on the complexity of the business problem being solved. A state-of-the-art virtual development environment takes care of accidental complexity (including plumbing) and leaves the developer to focus on the idea that is being implemented. This greatly accelerates time to value, provides developers with more satisfying work and reduces project risk.

Pure cloud application development requires all of the tooling and support to be run entirely and purposely in the native browser; this differs from the more historical approach in which the tooling is installed on a desktop and the applications are deployed into the cloud.

The important difference here with browser-based tooling is that collaboration and issue resolution is simplified because the tools don't have to be configured correctly on each device and the environment is not in play — removing the productivity-impacting issue of time needed to resolve issues related to getting the environments and configuration matching correctly.

By abstracting the application away from the platform, it is now possible to move the complete environment between any providers at will (be it on- or offsite) while still maintaining a consistent development environment.

The virtual nature of the environment means that it can be created, moved, or scaled at will. In response to a new customer or new application, an environment can be provisioned in a very short amount of time, allowing IT to be highly responsive. Since applications on these environments can be moved around with ease, virtual systems can be added, removed, and aggregated without needing to modify the applications running on them. This delivers on the utilitarian promise of cloud computing but now in the upper, most rewarding layers.

Back to top

The next generation of development systems

Combining these three visions together gives us a picture of the next generation of software development principles and systems, one that is designed to better serve the demands of users, to harness creativity, and to foster social collaboration. These systems will bridge the gap between business and IT, between users and data, and between contemporary personal, mobile and social computing, and enterprise computing.

All the aspects of a cloud environment apply here. Any environment (including development, test, or production) can be instantly provisioned, accessed from anywhere, scaled as demand increases, and is available with pay-as-you-go cost models. The environment might be in an internal environment or an external environment. Applications can be moved between environments without modification.

The application platform is user-centric, meaning that it tailors itself to the user's way of thinking. The user's ideas become first-class citizens in the conception of a new application. The environment focuses first on the way the application behaves to the user before it requires any data-centric components. Conceived elements of the applications behavior can be automatically converted into a working application for instant feedback.

Its socially collaborative nature means that anyone can review or contribute to the ideas or the running application at any time, specialists, team members, and remote experts. The application can be modified as it is running so that feedback can be incorporated without a build/release cycle. The application development environment is browser-based, allowing developers to collaborate from multiple locations in with many iterations in a single day if necessary.

Back to top

A real-world example

Now I'd like to introduce you to a real-world system that shows how to achieve the goal of user-centric, collaborative, virtual cloud application development: Aviarc and Aviarc DrawingBoard. I'll discuss how the systems work within the Think/Link/Ink paradigm described earlier. First, I'll describe the case study I'm using to illustrate.

Aviarc case study: Property Brokers marketing application

Background: Property Brokers is a large provincial real estate organization, dominant across central New Zealand. It offers a full spectrum of real estate services in 28 locations. Its portfolio include farms, rental properties, residential homes, lifestyle properties, and commercial/industrial investments and businesses properties.

Challenge: Property Brokers has an aging information system supporting all aspects of real estate activities. This centralized monolithic application system falls well short of meeting the company's information needs. Its processes are manual and have many repeated duplicate data entry steps. The company has been receiving complaints from field agents on the amount of non-value-added paperwork the system causes. Having seen a smart iPad application introduced by one of its competitors, Property Brokers perceived a threat that its system might be seen as unattractive and might even lose good sales agents due to the "hype" created by its competitor.

Direction: Property Brokers evaluated the various solution options and elected Aviarc and Aviarc DrawingBoard as the solution. The company understood the value in Aviarc's capabilities in designing a user-centric web solution that will have a major emphasis on user experience requirements. The company has a mandate to complete the conception in a short timeframe to showcase the offering and obtain buy-in from all sales agents.

Capturing ideas in the Think phase

The DrawingBoard and the Aviarc architecture change the fundamentals of the current software paradigm; they help manage complexity and promote innovative thinking.

The first stage is all about capturing in business and user friendly, big-picture terms, what evolves throughout the conception stage. Discussions start with broad abstract ideas that gradually become more structured.

For Property Brokers, Aviarc DrawingBoard was used for capturing thinking from the stakeholders and users. Figure 1 shows the DrawingBoard after the initial brainstorming.

Since DrawingBoard is web-based, users could review and contribute to the thinking and sharing beyond the realm of formal meeting rooms and forums. The phase may start with the user creating an initial Aviarc DrawingBoard; social collaboration between colleagues ensures that the Aviarc DrawingBoard captures the broadest needs. Each user can work with the skills, methods, and techniques that suit them best; for example, brainstorming or component business modelling. There is no need to have to learn new complex tooling or deal with a rigid process that gets in the way of creative innovation. At some stage the business users may invite an IT professional or some form of consultant to facilitate or mediate to help the business flesh out their thinking.

Users were able to run one or more workshops or simply work via the Aviarc DrawingBoard over the web. The output of this stage may be equated by some to the agile feature-driven approach, but the Aviarc DrawingBoard allows much more involvement iteratively by the business users, unconstrained by a linear process or unfamiliar techniques. The process is run by the business, for the business for as long as the business wants, until they determine that they are ready to move to the second part of the process.

An analogy would be if the project was to build a house, at this stage you would need to define the number and types of rooms, the general quality of fixtures, the number of floors, etc. This can all be captured within the Aviarc DrawingBoard. Ideas are represented visually as notes and are as simple as using a sticky note; these can then be linked together if, for any reason the user thinks this helps the thought process. Groups of notes can be exploded and imploded to handle scale and complexity simply.

Aviarc DrawingBoard was also used for communicating key messages about the progress of the initiative to management and other stakeholders and to the Project Manager who was travelling on the other side of the globe. Project Plans and progress updates were made available through the DrawingBoard. Figure 2 shows the dashboard that was used to articulate key messages about the project progress and also obtain any feedback from the user groups.

Relevant material can be attached to Aviarc DrawingBoard via specialized elements as part of the Think process: Notes, documents, videos, audios, people, profiles, roles, live websites, sketches, other Aviarc DrawingBoards, and so on. There is virtually no limit to the types of elements that can be visually and functionally incorporated into the design; new ones can be invented and added to the palette. These can be socialized by adding to them other elements such as chat rooms, votes, and watches that alert you to changes

The "desktop" on which the elements are being added and connected up can be simply replaced with any JPG picture which can depict a thinking tool, say a SWOT grid, swimlanes, or CBM layout. In this way virtually any consulting or thinking tool can be used to capture and organize thinking without needing to learn new techniques.

Anything that happens on an Aviarc DrawingBoard is also captured at its specific point in time so that at anytime in the life of the project, every addition or change to the thinking and design can be attributed within the context of the exact design. In this way, scope, probity, and the evolution of thinking can be sheeted home and never lost.

Organizing ideas in the Link phase

By this phase it was possible to settle on a well considered mutual agreement of scope (traditionally via a signed statement of work). Often it is already practical to set a fixed cost for completion of the remaining phases of the project. Nevertheless, features wanted later but not included in the scope at this stage can be added by trade-off or by a mutually agreed change to the scope.

Once the thinking is captured, the business analyst used the DrawingBoard to articulate the outcomes of analysis. Analysis outputs such as process maps, business facts abstractions, application theme design, application components are all abstracted in the DrawingBoard. Figure 3 shows one output from analysis phase.

As implied, by this stage it is usual to introduce a business analyst or other dedicated resource to the project to facilitate and moderate the continuing social collaboration of business users to develop the Aviarc DrawingBoard. As the analysis was progressing, work on experiential design began. Being an iPad application, the experiential needs were different from those of a normal PC-based browser experience. All items covered in the scope were expanded so that the user fully understands everything that will be constructed through "experiencing" it.

This was a highly iterative and traceable stage where supporting tools allowed various socially collaborative interactions to occur. Some examples include:

• The use of interactive, contextual on-application techniques (like Aviarc Pins) to clarify fine details and annotate aspects of the evolving application.
• The use of Aviarc DrawingBoard-based user tools that allowed the user to clarify various things like a drawing tool to modify the look and feel.
• The use of online Aviarc DrawingBoards, meetings, or workshops to explore larger areas or clarify things. Again with what was agreed being captured/recorded and confirmed by the users interactively on Aviarc DrawingBoard.

The conception stage may be an opportunity to capture requirements around performance and other non-visual (or experiential) needs of the application. These needs can also be captured/recorded using Aviarc DrawingBoard.

During the conception stage, the facilitating analyst will be able to grab existing artifacts from the Aviarc Marketplace; when he also creates artifact interfaces, these are optionally loaded into the Marketplace so that potential artifacts can be shared or co-created.

During the conception phase, speed and efficiency is gained by avoiding structural (or engineering) aspects — in other words, the house looks real but isn't yet so it would be very quick and easy to change something. The house (application) is only constructed visually (or experientially), so it is possible to create new rooms.

Screens are designed at this stage in the process with business users able to exploit a user friendly, simplified version of the studio facility within Aviarc. Other users can annotate, pin notes to, and socially collaborate on the screen design.

All entities are developed by users adding any relevant data or constraints to them, such as examples or use cases of types of data expected. From this Aviarc is able to derive most of the application logic and self-test as it quietly pieces together the application's flow and logic, deducing which elements will successfully work together and how the application will flow. See Figure 4.

As each element, connection, screen, and logic element is successfully completed and connected, the application starts to come to life; it will begin to look, feel, and act exactly as the production application will. It was possible to actually see the Aviarc-extensible XML code changing and developing automatically in the background of the Aviarc DrawingBoard. See Figure 5.

Using social collaboration via Aviarc DrawingBoard, there has been no translation, interpretation, or creation of a traditional two-dimensional specification at this point. Everything that's been done and captured lives as an integral part of the Aviarc application; the user community is still very much involved, interacting with the living, evolving project.

Late in this stage it was useful to conduct engineering assurance, to confirm everything in the virtual example could actually be built without hidden implications. In some instances engineering assurance will involve the need to change what has been conceived and "experienced" by the user.

In the virtual reality example, imagine the case where engineering has no way to run the pipes for plumbing a kitchen; it would have to come up with a couple of options and present them to the client for acceptance.

It is now time for Aviarc to auto-assemble the project: This is an automated process that can be repeated as often as needed. The process assembles all the extensible XML created and run during the Think and Link conception phases that can be automatically assembled. This typically can happen when you have 40 to 80 percent of the entire project ready for deployment (depending upon the type of project).

Auto-assembly can be carried out in one place by an individual with an auto assembly software key. The completion of this task signals:

• The end of the conception stages, although visual, contextual interaction with the application by the users will continue.
• The move into the more recognizable world of writing the remaining elements of the application by skilled team members.

Experience to date suggests organizations should expect the conception process (Think and Link) to take approximately one week of effort for every month previously experienced using best practice agile tools, techniques, and practitioners.

Constructing apps in the Ink phase

During the construction stage any elements specified during conception that were not auto-assembled (this includes changes required by any engineering assurance process) were completed. The application XML created during conception binds all of the components (to be constructed) together to complete the application — in other words, the application now always looks and behaves exactly as experienced during conception.

Using the Aviarc development platform, practitioners can rapidly construct any remaining complex logic and data-handling elements. Aviarc DrawingBoard provides very specific guidance to the exact design and construction of these elements.

The working application also provides a clear context within which to fit these manually constructed elements. They can be readily and instantly tested by the developer for fitness of purpose, but also fit to the rest of the app. Often these elements already exist in the Aviarc Marketplace, standard element libraries, or you can even reuse elements from earlier work within the location.

When you do have to manually develop a logical element, DrawingBoard makes it quick and easy.

The work done in this phase is quite suitable for off-shoring to specialists, still allowing your team to work effectively and efficiently (and collaboratively) with outside programmers.

The final act before deployment of the new Aviarc application is user acceptance of what has been constructed against what was conceived. The best test: A user should notice no difference between what is anticipated (and was experienced in early stages in simulation) and what results.

Back to top

In conclusion

Recently, cloud computing itself was considered an emerging (if not re-emerging) technology. Now, how to develop applications using a user-centric, collaborative, virtual approach that employs cutting-edge technology like cloud environments are emerging and promise to alter, if not revolutionize, the way application development is done.

Time-to-development has become an important aspect in an increasingly competitive application market. That time not only includes the logical underpinnings of an application, the programming code, but also encompasses user interactional behaviors of the application. You not only need to reduce the time and effort required to get the coding right, you have to be constructing the application the user wants and expects right from the start. Code reuse and modularization has been around on the programming side for quite awhile; with the user-centric, collaborative, virtual approach I propose, you can also reduce the time and effort to produce the user-required application.

And the structure of the cloud is the perfect environment where this can take place.

In the environment I've proposed, the user community — however you want to define that — is able to intuitively, visually interact at will with each other, with every single aspect of the idea and design process, and with the virtually and actually running application. I've seen users pinch themselves in disbelief when they realized that a change they made to the parameters shows up in the virtual application.

What are some consequences of this approach? A small number of unexpected consequences have started to emerge:

• More doubters are believing in the capability and capacity of IT to meet the swiftly changing and urgent needs of the business users with a highly appropriate experience and outcome.
• With tight integration to data-centric systems, we're seeing more and fuller use of those traditional systems, as well as SOA, ESB, and other good practices creeping over into the new user-centric systems.

Here's what I see in the future of user-centric development systems:

• A steady increase in the percentage of application completion via some sort of auto-assembly, continuously delivering faster-to-market applications (and making organizations more and more adaptive and innovative).
• A rapid evolution of the socially collaborative development experience and tooling to go along with it; an ever more "gamified" or intuitive engagement for the user and IT professional alike.
• The building of extensive amounts of tradeable IP.

Finally, I think we'll see really dramatic benefits from cloud computing technology compared to what we've seen so far. Eventually the lines between in-house technology stacks and tools and cloud technology stacks and tools will blur as development becomes a collaborative industry.

Resources

Learn

• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Find out how to access IBM SmartCloud Enterprise.
  
  

Get products and technologies

• See the product images available for IBM SmartCloud Enterprise.
  
  
• Aviarc is an enterprise software design and development platform that allows developers, business analysts, and potential users to collaborate on application development in a way that provides a user-designed application "framework" that can be easily adapted by all members of the planning team and provides instant feedback to changes through a virtual simulation of the application.
  
  
• Aviarc DrawingBoard is an integrated visualization tool with powerful abstraction, collaboration, and conception capabilities.
  
  

Discuss

• Join a cloud computing group on developerWorks.
  
  
• Read all the great cloud blogs on developerWorks.
  
  
• Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• What does this mean to IT professionals?
• A vision of a user-centric development environment
• A vision of a collaborative development environment
• A vision of a virtual development environment
• The next generation of development systems
• A real-world example
• In conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers