Why Create an Enterprise App Store?   Goals!

• Obtain a user-friendly experience commonly found in consumer app stores
  • Business teams and individuals can rapidly find useful applications that will help them perform their tasks, increase their productivity, or obtain relevant information.
  • Business teams and individuals can directly subscribe to applications and use the application without IT intervention.
  • Companies can efficiently maintain budget, access, and compliance controls
    • IT groups can promote application solutions that conform to corporate policies (e.g. security, service level, budget) and are pre-integrated with corporate resources (e.g. identity directory, workflow, content, structured data, business processes).
    • IT groups can manage licensing, distribution, and upgrades that impact overall IT spend and user experience.
    • IT groups can provision access when employees on-board and turn-off access when an employee leaves the project or company.

What are Enterprise App Store Challenges?  Hurdles!

• Promoting and displaying applications that are relevant to the enterprise app store user.
• Understanding license and infrastructure costs
• Establishing and maintaining access approval and budget approval processes.
• Eliminating lengthy identity and access provisioning tasks
• Controlling the distribution and upgrade of applications on mobile devices
• Integrating applications with corporate resources
• Delivering dashboards providing visibility into application subscriptions, usage, license audits, and policy compliance.

How to Create an Enterprise App Store – Execution!

• Create on-demand, automated provisioning of application access and application configuration
• Integrate user identity and single sign-on (SSO) with App Store
• Ideally, select apps that are OAuth compliant and integrate with identity management and authorization infrastructure
• Apply policy based promotion, access control, and data security policies to apps and APIs
• Create branded App Stores that target a segment of the enterprise user population (e.g. HR, call center, sales force, field engineer)
• Interface enterprise app store with mobile device management (MDM) infrastructure

Apache Tomcat is known for it’s ease-of-use and minimal footprint when building servlet and JavaServer Page applications, while Apache Camel is known for supporting Enterprise Integration Patterns, routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL.

Developers and architects find a straightforward learning curve when using Apache Camel’s Java based DSL, yet they find better tools exist when building simple connections or implementing large integration projects. See Kai Wahner’s writeup on lightweight frameworks.  For larger integration projects requiring reliable messaging, scalability, eventing, business process execution, or web agent hosting, selecting an Enterprise Service Bus provides a better fit.  Kai has another good article placing ESB and integration suites in context.   Apache Camel is often integrated with ActiveMQ, ServiceMix, or Fuse to obtain additional capabilities required to deliver medium to complex integration projects.  The WSO2 ESB team is looking to embrace the simplicity of Apache Camel (by incorporating the project similar to embedding Apache CXF), and extend with multi-tenancy, failover, performance, and scalability enhancements.

Similar to RedHat JBoss Fuse, WSO2 ESB delivers service container clustering and reliable failover functions.   In addition to extensive mediation primitives, the products provide service monitoring and management support not available in the basic Apache Camel with Apache Tomcat combination.

To combat server proliferation, WSO2 ESB inherently supports multi-tenancy.  The multi-tenancy goes beyond simple Tomcat virtual domains by using OSGI class loaders and security managers to provide adequate tenant isolation and separate administration console interfaces.  A single WSO2 ESB instance can support multiple business units with appropriate data, logic, and execution isolation.

SpringSource, MuleSoft, and WSO2 have extended Apache Tomcat to provide better server management and ability to install features within the integration platform.    WSO2 ESB can install over 100+ features (e.g. business process execution, complex event execution, business activity monitoring) into the integration platform.

From performance perspective, Apache Camel with Apache Tomcat depends on the Tomcat transport to provide high performant message transfer.   The WSO2 ESB pass through transport and binary relay transports are optimized to provide the best streaming, non-blocking performance by tightly integrating the transport and mediation layers.

Camel + Tomcat depends on what ever the Tomcat transport support but I believe ESB PT and NHTTP transports are preforming efficiently here but i also don’t have any reference.  If you install Apache Camel on top of Apache Tomcat then you are not going to get the same performance and scalability.   The latest ESB performance benchmarks are posted for reference and replication.

How are you building a pragmatic, open source driven game plan that incorporates New IT approach vectors?

The path to New IT requires incrementally moving away from traditional application platforms, traditional team structure, and traditional information flows.  The New IT architecture underlying Responsive IT intelligently incorporates Cloud Platforms, BigData Analytics, Enterprise DevOps, and API first development.

In a New IT operations model, instead of being a single-purpose delivery team, IT serves as a broker and validator of solution building blocks.  IT focus and responsibility shifts towards creating an ecosystem delivering composable and reusable IT capabilities.   Project teams can access open APIs, services, business processes, open data, and applications to compose the assets into new solutions.  The operations model safely shifts

the center of project responsibility to project individuals and business units while maintaining IT as a more valued business partner.   IT maintains responsibility for policy compliance, serves as a trusted technology advisor, and mentors teams on IT capability usage.  Corporate IT delivers ‘solution accelerator packs’ that decrease time to market, reduce development hurdles, and cost effectively implements corporate policy.

To build a New IT delivery model, adopt a platform supporting cloud integration, cloud run-time, cloud DevOps, application services governance, API and mobile enablers.

Figure 1: Building Blocks of a New IT Delivery model driving Connected Business

Cloud run-time platforms with shared container resource pooling, elastic load balancing, and on-demand scalability provide an efficient deployment environment that enables solutions to target low usage or low margin business opportunities.

Cloud DevOps changes the IT operating model to one of continuous innovation based on micro-iterations.  Teams adop continuous integration, continuous test, and continuous deployment practices.  The practices rely on dynamic provisioning and infrastructure as code to automate activities and provide self-service access.

Application Service Governance is required to create a trusted environment that encourages adoption.   By introducing deployment synchronization, service level management, and automated governance, teams foster open collaboration across internal development teams, business units, and partners.

Enabling mobile apps and prolific API-first development requires an API management platform offering API promotion, API self-service subscription, and mobile access.

Cloud integration augments enterprise integration by offering self-service access, cloud connectors, federated identity, and multi-tenancy.

Adopting a New IT delivery model and changing the IT-business dynamics is not an easy task.  Traditionally, application platforms have inhibited change, blocked agility, and discouraged best practices.  Platform as a Service offerings delivering DevOps, Analytics, Integration, and Governance best practices provide a viable ramp onto the path to responsive IT.

Figure 2: Platform as a Service Focus Areas connect IT domains

Recommended Reading

Open Source Business Conference Impressions

New Enterprise IT Drivers

A Path to Responsive IT

A New IT Plan

New IT Steps to Accelerate Agility

Open Source startups (e.g. HortonWorks, 10gen, Appcelerator, GitHub, Netflix, SUSE, and WSO2) are leading their respective technology domains by encouraging open collaboration, micro-iterations, and user-led innovation.

Open collaboration is occurs within the diverse Linux, Apache, and OpenStack open source communities, and also in infrastructure ecosystem partnerships (i.e. mobile device providers and mobile application platform vendors, operating system vendors and application platform vendors, or Big Data infrastructure vendors and Cloud analytic providers).  Shaun Connolly described how open collaboration is shaping Big Data and Cloud technology.

The rapid pace of technology change is forcing companies to adopt agile product strategies that rely on micro-iterations to fine-tune market impact.   Three and five year plans are rapidly rendered irrelevant by the rise of new market forces (e.g. think about the world before GitHub, before Twitter, before iPhone, before NetFlix, before Amazon).   James Staten outlined how Cloud is still in an early adopter phase with significant opportunity for new leaders to emerge.

The open source ethos of open collaboration and listening to users is providing open source companies an edge in a user-led environment.   Mobile adoption, technology consumerization, data democratization, and Cloud self-service access are shifting the market’s paradigm towards user-led innovation.

A telling data point is how Adrian Cockcroft from Netflix captured interest at the PaaS lunch table discussion and presented to a standing room only crowd on the last day.    Roman Stanek illustrated how his company, Good Data, is successfully democratizing the rarified world of business intelligence and analytics.  When Software as a Service and streaming movie companies lead the discussion, one can clearly see the paradigm shift on the big screen.

My conference contribution was to outline a New IT Plan that embraces the disruptive business forces reshaping technology offerings.   After pondering the conference experience, I believe the plan will be recalculated and re-factored.  My thanks to many conference participants and speakers whose insightful conversations are shaping the next micro-iteration.

I look forward to the next Open Source Business Conference, and obtaining an update on how organizations are adapting to a market environment shaped by open collaboration, user-led innovation, and micro-iterations.

Traditional corporate structure is dissolving into flexible value-webs of business participants.  The business participants dynamically band together on a project, disperse, and reform around new business opportunities.  Because new discovery and connectivity mechanisms lower interaction cost, group formation and participation is fostered. Figure 1 below illustrates how organizational dynamics are changing and a New Enterprise is being born.   Instead of all corporate functions being performed in-house, offshoring, outsourcing, temporary contractors, and dynamic partnerships drive today’s agile New Enterprise business.

Figure 1:  The Breakup of the Corporation

New Enterprise organizations are defining Connected Business Strategies that rely on big data analytics, contextual personalization, industry ecosystems, and advanced monetization to create new business models.

Figure 2: Connected Business Strategies

Queuing, waiting, and the status quo doesn’t fit well with today’s “now generation’ and New Enterprise dynamics.  Business stakeholders, who drive revenue growth and customer retention, desire to rapidly seize opportunity and market share.  They often view IT timeframes and capabilities as a poor match for today’s fast business-pace.

IT often is geared to only service high-impact, mission critical projects.  A large amount of data access, analytics, and workflow requirements are unmet by the one-size-fits-all, tightly allocated IT service model.   To maximize business flexibility and agility, New Enterprise IT meets The Long Tail of application and analytic demands with new platforms.   Figure 3 illustrates the service scope of Old IT and New Enterprise IT.

Figure 3: The Long Tail and IT Coverage     Source: Gartner 2011

A New IT model is required to reduce delivery time and accelerate business agility.  How are you building a pragmatic, open source driven game plan that incorporates New IT approach vectors, Open DevOp PaaS, Open APIs, and Open Ecosystems?

The complete presentation delivered at the Open Source Business Conference on April 29 is posted.    Learn more about New Enterprise drivers, a New IT plan, and network with open source community leaders.   The conference covers the open source strategic challenges that IT management deals with on a daily basis.

Recommended Reading

New IT Plan

A Path to Responsive IT

Accelerate Business Agility

As a techie, I like to focus on the technology and IT process side of DevOps; bouncing around terms like ‘infrastructure as code’, ‘automated provisioning’, ‘continuous deployment’, and ‘continuous integration’.   The value-prop is self-evident to me and many of my peers. Yet, for us to change corporate culture and rally around a New IT Plan, the main message focus must not be  ’DevOps for DevOps Itself’, but to create a Responsive IT team that changes business-IT dynamics and accelerates business agility.

DevOps is not about ‘creating a better ALM’, but about working together as a single team, reducing wait times, automating repetitious tasks, and accelerating business innovation iterations.  While the ‘NoOps‘ model is subject to confusion and derision, reducing manual activity and operation desk tickets is a straightforward goal.

Define infrastructure as code, automate manual actions, and create self-service interfaces that take the operator out of the middle.  Teams usually invest a significant amount of work to build a more agile, self-service environment, or they can choose a ready-made DevOps PaaS that can be configured to match their workflow stages, gates, approval processes, and infrastructure templates.

Teams can measure progress by tracking the reduction in DevOps tickets, shorter ticket close average, and increased solution iteration count.

Recommended Reading

DevOps Driven Demand by Dan Ackerson

Accelerate Business Agility with App Factory DevOps PaaS

A New IT Plan: Enterprise DevOps PaaS, API Management, and Ecosystem Platforms

A Path to Responsive IT

Cloud native PaaS architecture requires infrastructure innovation in provisioning, service governance, management, deployment, load-balancing, policy enforcement, and tenancy.  Cloud native, innovative provisioning infrastructure increases tenant density and streamlines code deployment and synchronization. Multi-tenancy within middleware containers enables teams to customize applications and services per consumer by changing run-time configuration settings instead of provisioning new instances.

A Cloud platform may automate governance and enforce policies (i.e. security, service level management, usage) through enterprise PaaS services.  Cloud provisioning may fulfill enterprise deployment requirements across all service providers and technologies used by solution delivery teams.

To re-invent the platform and achieve benefits, new Cloud Native platform architectural components and services are required.   Traditional client-server and N-tier web application architectures do not exhibit requisite cloud characteristics (i.e. elastic scalability, multi-tenancy, resource pooling, or self-service).  Figure 1 below depicts the new Cloud Platform architectural components and services.   The PaaS controller layer deploys, scales, monitors, and manages an elastic middleware Cloud. PaaS Foundation services provide common solution building blocks.  A complete, comprehensive, and Cloud-aware middleware container layer delivers new cloud-aware capabilities to business applications.

The middleware container layer should not be tightly coupled to the PaaS foundation.  A cartridge or droplet pattern is used to support running any application or service container on the PaaS.   By providing a cartridge plug-point, Cloud Native PaaS environments can run any language, framework, or server (after appropriate integration via the cartridge API and agents).

Figure 1: Cloud Platform Architecture Components and Services

Elastic Load Balancer

Elastic Load Balancer (ELB) balances load across cloud service instances on-premise or in the cloud. The ELB should provide multi-tenancy, fail-over, and auto-scaling of services in line with dynamically changing load characteristics.   Cloud Native Elastic Load Balancers are tenant-aware, service-aware, partition-aware, and region-aware.  They can direct traffic based on the consuming tenant or target service.   Cloud Native Elastic Load Balancers manage traffic across diverse topologies (i.e. private partitions, shared partitions, hybrid cloud), and direct traffic according to performance, cost, and resource pooling policies.   A Cloud Native ELB is tightly integrated with the Service Load monitor component and dynamically adjusts to topology changes.

Service Load Monitor

The Service Load Monitor component acquires load information from multiple sources (e.g. app servers, load balancers) and communicates utilization and performance information to an Elastic Load Balancer responsible for distributing requests to the optimal instances, based on tenant association, load balancing policies, service level agreements, and partitioning policies.

When the level of abstraction is raised above Infrastructure as a Service (IaaS) instances, Teams no longer have direct access to specific virtual machines.  New Cloud Native components are required to flexibly distribute applications, services, and APIs across a dynamic topology.  A Cloud Controller, Artifact Distribution Server, and Deployment Synchronizer perform DevOp activities (i.e. continuous deployment, instance provisioning, automated scaling) without requiring a hard, static binding to run-time instances.

Cloud Controller

A Cloud Native Cloud Controller (or auto-scaler) component creates and removes cloud instances (virtual machines or Linux containers) based on input from the Load Monitor component.   The Cloud Controller right-sizes the instance number to satisfy shifting demand, and conforms instance scaling with quota and reservation thresholds (i.e. minimum instance count, maximum instance count).   The Cloud Native Cloud Controller may provision instances on top of bare metal machines, hypervisors, or Infrastructure as a Service offerings (e.g. Amazon EC2, OpenStack, Eucalyptus).

Artifact Distribution Server

The Artifact Distribution Server takes complete applications (i.e. application code, services, mediation flows, business rules, and APIs) and breaks the composite bundle into per-instance components, which are then loaded into instances by a Deployment Synchronizer.  The Artifact Distribution Server maintains a versioned repository of run-time artifacts and their association with Cloud service definitions.

Deployment Synchronizer

The Deployment Synchronizer checks out and deploys the right code for each Cloud application platform instance (e.g. application server, Enterprise Service Bus, API Gateway).   With infrastructure and servers abstracted and encapsulated by the Cloud, a Cloud Native PaaS Management Console allows control of tenant partitions, services, quality of service, and code deployment by either Web UI or command-line tooling.

Cloud Native PaaS Architecture Business Benefits

Cloud Native PaaS architecture accelerates innovation, increases operational efficiency, and reduces cost.

The traditional, keep-the-lights-on, operational run-rate consumes precious resources and limits innovative new projects.  By optimizing project footprint across pooled resources on a shared Cloud Native PaaS infrastructure, Responsive IT can reduce operational spend, improve total cost of ownership (TCO), and make more projects financially viable.   Multi-tenant delivery models create an efficient delivery environment and significant lower solution deployment cost. For more information on the financial benefits of multi-tenant, Cloud Native platforms, read the white paper.

By building a Cloud Native PaaS environment, you provide your teams with a platform to rapidly develop solutions that address connected business use cases (i.e. contextual business delivery, ecosystem development, mobile interactions).

Recommended Reading

A Path to Responsive IT

PaaS Services

Does your PaaS architecture show a paradigm shift?

Cloud-aware Applications and PaaS Architecture

Providing a who’s who in the vendor market, this research offers basic profiles for vendors that qualify to provide a comprehensive set of application infrastructure supporting an organization’s projects in the next three to five years.

Gartner cites WSO2 as a visionary in all three Magic Quadrants for Application Infrastructure including SOA Application Projects, Systematic Application Integration Projects, and Systematic SOA Infrastructure Projects. Of the vendors listed as options in the Comprehensive Application Infrastructure report, WSO2 is the only open source vendor included.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose

While at Burton Group, Anne and I advised clients on how to navigate the best-of-breed vendor versus super-platform vendor choice.  An amazing aspect of the WSO2 application infrastructure platform is the breadth and depth of application infrastructure capabilities.

Before you set your championship plans for this year, view the Gartner report and train for the open source majors.

The path to New IT requires moving away from traditional application platforms, traditional team structure, and traditional information flows.  Responsive IT teams are adapting their infrastructure, processes and tooling to re-invent the application platform and re-think application delivery.  The New IT architecture underlying Responsive IT intelligently incorporates Cloud Platforms, BigData Analytics, Enterprise DevOps, and API first development.

How are you building a pragmatic, open source driven game plan that incorporates New IT approach vectors, Open DevOp PaaS, Open APIs, and Open Ecosystems?

Adopting an Open Enterprise DevOps PaaS can align your IT model with business agility expectations.

DevOps principles and practices combined with PaaS characteristics will quicken IT solution development and delivery.   A DevOps focus on continuous activity execution (e.g. continuous build, continuous integration, continuous test, continuous delivery) creates a ‘no wait’ environment.   Teams do not have to wait for the next script to run or for the next activity to commence.  By incorporating automation into developer and operations processes, teams bypass time consuming manual tasks and gain faster phase execution.  Both DevOps and PaaS promote simple, on-demand self-service environments that shield team members from complexity and reduce skill hurdles.  By offering on-demand self-service access, rapid business innovation and experimentation is possible. By reducing complexity, team members are not required to obtain special training and skills before consuming IT services and infrastructure.

PaaS increases agility by democratizing access to IT infrastructure and services.  Offering a low cost environment and increasing resource availability, PaaS promotes democratized access.   The chosen PaaS environments must offer required application building blocks available on-demand, and minimize cost by amortizing infrastructure expense over multiple project teams.   PaaS environments based on multi-tenant, shared application containers facilitate pervasive access by increasing tenant density and lowering tenant cost.   Affordable, pervasive on-demand access encourages project teams to use approved PaaS environments and enables shadow IT teams to efficiently and safely create a long tail of application development projects.

To read more about Enterprise DevOps PaaS accelerating team agility, read a recent blog post.

Open APIs are empowering developers by delivering business building blocks.

Teams can rapidly compose solutions to meet shifting business demand by re-using Open Data and Open APIs. Teams are embracing long tail development communities that enable innovative business ecosystem strategies to emerge, with Open Data and Open API foundations.

In a New IT operations model, instead of being a single-purpose delivery team, IT serves as a broker and validator of solution building blocks.

IT focus and responsibility shifts towards creating an ecosystem delivering composable and reusable IT capabilities.   Project teams can access open APIs, services, business processes, open data, and applications and compose the assets into new solutions.  The operations model safely shifts the center of project responsibility to project individuals and business units while maintaining IT as a more valued business partner.   IT maintains responsibility for policy compliance, serves as a trusted technology advisor, and mentors teams on IT capability usage.  Corporate IT delivers ‘solution accelerator packs’ that decrease time to market, reduce development hurdles, and cost effectively implements corporate policy.

How are you building a pragmatic, open source driven game plan that incorporates New IT approach vectors, Open DevOp PaaS, Open APIs, and Open Ecosystems?

View the New IT Plan deck presented at  Open Source Business Conference on April 29-30 to learn more about the New IT plan and network with open source community leaders.   The conference covers the open source strategic challenges that IT management deals with on a daily basis.

Key WSO2 application services governance platform components participating in policy enforcement, decision, and storage include:

• WSO2 Governance Registry
• WSO2 API Manager
• WSO2 App Factory
• WSO2 Identity Server
• WSO2 Business Process Server
• WSO2 Complex Event Processor
• WSO2 ESB
• WSO2 Elastic Load Balancer

WSO2 Governance Registry serves as a policy store for any type of runtime policies including security policies, lifecycle management workflow policies, API policies, service description, service contracts, service consumption, service usage, service lifecycle management, service level agreements (SLAs) and XACML authorization policies. The WSO2 stack has built-in support for a number of standards, including WS-Policy, XACML 3.0 and SCXML.

WSO2 API Manager delivers an application services governance experience tuned for self-service, on-demand access, and safe API usage.  API governance management encompasses service level policies, usage policies, version policies, subscription policies, and access control policies.

WSO2 App Factory governs and manages application lifecycle policies, infrastructure access policies, and application versioning policies. WSO2 App Factory solves first-mile issues when developing and testing services

WSO2 Identity Server serves as a policy decision point and policy manager for sophisticated security policies encoded in XACML.

WSO2 Business Process Server is a general-purpose workflow engine used by WSO2 Application Services Governance Platform products to execute governance workflow, present task lists, and manage approvals.

WSO2 Complex Event Processor can be configured as a policy decision point, which uses time-based policy pattern matching to evaluate run-time service, message, REST resource, and event traffic.

WSO2 ESB (and all WSO2 products) serve as well-integrated policy enforcement points that may delegate policy decisions to external decision points or internally cache and process policy assertions.

WSO2 Stratos and WSO2 Carbon middleware components (i.e. WSO2 Elastic Load Balancer) deliver sophisticated run-time policy enforcement for tenant partitioning, service level management, application provisioning, tenant access, and resource management.

Policy Management Capabilities

The WSO2 Application Services Governance Platform provides advanced policy management capabilities across design-time, run-time, security, and lifecycle management focus areas.

Design-time policy management

The WSO2 Governance Registry ensures all standard design-time policies, and provides a highly flexible policy management framework, where teams can add new policies and policy validations as extensions using common plug-points. For example, teams can extend basic authentication policies and validate that a minimum level of WS-Security is used on all services. The WSO2 Application Services Governance platform supports all design-time policy management activities listed in this document.

Run-time policy management

Run-time policy management is implemented using a fit-for-purpose combination of WSO2 Enterprise Service Bus, WSO2 API Manager gateway component, WSO2 Cloud Gateway, WSO2 Mobile Gateway Solution, WSO2 Elastic Load Balancer, and/or WSO2 Stratos Cloud Platform.

WSO2 API Manager clients commonly manage and govern API run-time interactions according to specified API service tier policies (e.g. rate limits), subscriptions, and access policies.  In an ESB or API gateway serving as a policy enforcement point, specific service subscribers can be rate limited, traffic can be throttled, malicious messages discarded.  Additional run-time policy mitigation is possible, and in fact, any flow can be defined (e.g., log, send back a fault to the client, start diagnostic process, send event to management components, or fire off a BPEL workflow process with human activity interactions).  Cloud controllers adjust topology and traffic to rectify service level policy breaches. For example, start a new elastic instance to handle more loads.

Additionally, the WSO2 Application Services Governance platform supports a diverse number of run-time policy management activities.

Security Policy Management and Enforcement

The WSO2 application services governance platform supports open Web protocols and popular enterprise protocols including OAuth, SAML2, WS-Trust STS, Kerberos, and Active Directory. The WSO2 applications service governance platform can be interfaced with third-party security policy enforcement systems, including Microsoft Windows Identity Foundation for .NET applications.

Service and Application Lifecycle Management

WSO2 App Factory enables teams to govern and manage application lifecycle promotion and versioning.  Development teams may define custom gates, checklist items, and promotion/demotion rules to govern and manage application lifecycle processes.

The WSO2 Governance Registry, WSO2 API Manager, and WSO2 App Factory implement a very simple, powerful, flexible model for lifecycle states and stages.

The default WSO2 Governance Registry configuration presents a streamlined lifecycle management process that may be modified to match client governance policies.  The management interface presents mandatory and optional checklist items.

The default WSO2 API Manager’s lifecycle management process defines ‘created’, ‘published’, ‘deprecated’, ‘retired’, and ‘block’ states.  Team members in the ‘API Creator’ role may define an API and place it in the initial ‘created’ stage.  Team members in the ‘API Publisher’ role may transition APIs across subsequent lifecycle stages.

WSO2 App Factory  provides service implementation project-level governance and management. WSO2 App Factory automatically executes application service (service or API) integration tests, compliance tests, and performance tests.  Teams may assess test results before promoting service implementations.

Lifecycle Management Model

As the lifecycle management model is based on the WSO2 Business Process Server and a robust workflow execution engine, the model is completely flexible and can be extended in Java, script languages, or BPEL.  Many clients use the “default” (out of the box) model with minimal customization.

The default model is based on the W3C standard State Chart XML (SCXML), which is an XML model of a state machine. Each lifecycle stage is defined as a state and transitions between these are defined as actions that users can take. Each transition has a set of “checklist” pre-conditions that can be tested, together with role-based security to ensure that only the correct role can “check” an item off. In addition, code can be used to calculate checkbox states or form preconditions. Code can be triggered on transition as well. SCXML has a graphical view, which will become part of the tooling around lifecycles.

The result is that the governance teams can quickly and easily create effective lifecycle policies. The WSO2 Application Services Governance Platform presents fit-for-purpose governance environment (WSO2 Governance Registry for services, WSO2 API Manager for APIs, or WSO2 App Factory for applications) offering users a simple-to-use UI that allows users to promote or demote assets in the lifecycle. The SCXML model also supports “branching lifecycles” where assets can go down different paths (e.g. passing external services through an extra security assessment).  Lifecycle stage transitions may trigger run-time enforcement actions.  For example, changing an API stage to ‘Deprecated’ will prevent future subscriptions.  Changing an API stage to ‘Blocked’ will deny API calls.  In WSO2 App Factory, changing service implementation stage will automatically deploy or un-deploy service implementation artifacts from run-time cloud environments (i.e. Dev, Test, Production).

Recommended Reading

 Application Services Governance

Policy Management Overview

Governance relies on policy, people, process and technology to guide business activity and consistently deliver positive outcomes. Effective governance channels business activity towards the ‘right’ path; by making the right actions the path of least resistance.

To efficiently guide teams and demonstrate policy compliance benefits, Application Services Governance Platforms provide policy management, developer portals, repositories, service integration and composition, and business value dashboards.

Effective governance encompasses the entire IT solution spanning APIs, services, business processes, data, and application delivery.   While most governance solutions focus on web services, leading Application Services Governance Platforms bridge API governance, SOA governance, Cloud deployment governance, data governance, and application delivery governance.  Additionally, the governance experience must be tailored for the participant’s project role.

Portals may be personalized to present notifications, tasks, actions, and reports suitable for application service creators, publishers, subscribers, consumers, or business managers.   Application delivery governance segments participants into developers, quality assurance testers, operations, project managers, and application users.

End-user Application Services Governance priorities are evolving toward bridging service governance with API governance, extending application lifecycle management to embrace cloud deployment environments, and focusing on visualizing asset business value.   Key governance challenges include meeting mobile application demands, implementing efficient self-service provisioning, right-sizing governance practices (not too heavy or light), and defining appropriate policy tiers.

Governance Components

To efficiently guide teams and demonstrate policy compliance benefits, Application Services Governance Platforms provide policy management, developer portals, repositories, service integration and composition, and business value dashboards.

Figure 1 Application Services Governance Components

Policy Management

Policy management is used to specify the correct behavior, detail exception thresholds, and define corrective actions or notifications.   Leading application services governance platforms deliver advanced policy management by conforming to a flexible architecture, addressing relevant policy categories, and spanning all lifecycle phases.

A comprehensive Application Services Governance Platform manages:

• Design-time Policy
• Run-time Policy
• Security Policy
• Developer access Policy
• Service and API Lifecycle Management Policy
• Application Lifecycle Management Policy

Within these six broad categories, application services governance commonly encompasses service level policies, usage policies, version policies, subscription policies, and access control policies.

Registries serve as policy stores for many types of runtime policies including security policies, lifecycle management workflow policies, API policies, service description, service contracts, service consumption, service usage, service lifecycle management, service level agreements (SLAs) and XACML authorization policies. Leading platforms have built-in support for a number of policy standards including WS-Policy, XACML 3.0, and SCXML.

Cloud foundation and cloud middleware components deliver sophisticated run-time policy enforcement for tenant partitioning, service level management, application provisioning, tenant access, and resource management.

All run-time infrastructure products should serve as well-integrated policy enforcement points that may delegate policy decisions to external decision points or internally cache and process policy assertions.  Identity Management infrastructure components serve as a policy decision point and a policy manager for sophisticated security policies encoded in XACML.

The Application Service Governance Platforms use workflow engines to execute governance workflow, present task lists, and manage approvals. Complex Event Processor components can be configured as policy decision points, which use time-based policy pattern matching to evaluate run-time service, message, REST resource, and event traffic.

For more information on policy management, read the detailed policy management blog post.

Developer Portal and Repository

Portals serve as the viewport into policy management, service integration and composition, and business value dashboards.  The Application Service Governance portals should deliver an application service governance experience tuned for self-service, on-demand access, and safe API usage.

Developer portals are often contextually personalized to fit the project and user’s role.  For example, a developer portal may fit the needs of API creators and API publishers who are defining, documenting, and publishing APIs.  The portal’s user experience may enable API creators and publishers to monitor, manage, and analyze API usage.  A developer portal may also be personalized to deliver a user experience tailored for API consumers.  API developers who are consuming APIs can find, explore, subscribe and evaluate APIs.

Developer portals are often tuned to facilitate service meta-data and lifecycle management for service creators.  Service and integration developers who are consuming services can find and explore services.  A developer portal should guide teams toward effective and efficient governance when building service implementation and service consumption code.

Advanced developer portals capabilities include overlaying build management governance, test governance (i.e. unit, integration, performance), implementation lifecycle governance, and deployment governance.

An Application Services Governance Platform should enable flexible organization, classification & documentation of services, APIs, and any IT asset.  Key repository capabilities include governing and managing:

• Any type of metadata in any structure
• Service, API, or artifact associations and relationships
• Schema definitions and namespaces
• Users and Roles
• User subscriptions
• Service level agreements
• Developer documentation
• Social taxonomies (e.g. ratings, comments, tags)
• Implementation artifacts (i.e. code, test cases)

Service Integration and Composition

Service integration and composition for APIs, web services, or business process are often implemented using tools provided by the run-time infrastructure vendor.   Application Services Governance components must integrate into diverse run-time infrastructure containers and development tooling.  Synchronizing policy, development artifacts, and deployment packages requires tight integration between design-time tools, development tools, run-time management consoles, and application services governance portals and repositories.

Business Value Dashboards

To gauge governance effectiveness and enhanced business value, analytic dashboards assess policy compliance, quality of service, service usage, architecture coherence, and team performance.

The Application Services Governance platform should capture service tier subscription information, collects usage statistics, and integrate with billing and payment systems that deliver show-back or charge-back reports.  Subscription and usage reports help teams understand asset adoption (by version, by service) and usage (by version, by service).  By understanding adoption and usage, business owners and architects can intelligently invest future development resources, properly plan infrastructure scale, and rationalize the portfolio.

Dashboards also present a service overview, number of services, service lifecycle stage, schema re-use, service dependencies, upgrade impacts, development team productivity, and project progress.

Governance Lifecycle Phases

API management portals and SOA Governance Registries must work together to keep API lifecycle stages synchronized with backend service implementation stages.  An API Governance experience may provide a straightforward set of lifecycle stages (e.g., created, published, deprecated, retired, blocked) that may be customized by the development team.  SOA Governance Registries facilitates service metadata management and governance across design, implementation, test, and run-time operations.  Figure 2 below depicts the intersection of the two governance views.

Figure 2: API and Service Lifecycle Views

Application delivery governance usually relies on ad hoc tools and processes, knitted together by end-user delivery managers.   Application Services Governance Platforms should span project inception, development, quality assurance, production deployment, production management, maintenance, and retirement.  Figure 3 illustrates service implementation activities governed by an application delivery governance product.

Figure 3: Implementation activities governed by application services delivery governance

Application Services Governance Drivers

The IT focus on API, DevOps, and Cloud scale is driving resurgent interest in Application Services Governance.

As development teams support mobile applications by fielding web APIs, they are creating a new ‘demand layer’ in front of existing service implementations.  Both API and SOA success requires creating loosely coupled consumer-provider connections, enforcing a separation of concerns between consumer and provider, and exposing a set of re-usable, shared services, and gaining service consumer adoption.   With traditional SOA Governance, many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams.

In today’s connected business world, API and SOA are the business. An effective governance approach must address human collaboration stumbling blocks. By publishing managed APIs, establishing API manager and publisher roles, extending the governance registry, facilitating API management practices (e.g self-service key management, self-service provisioning, service tier management, and usage visualization),and offering APIs through developer portal, organizations can overcome collaboration, trust, and adoption hurdles while enhancing SOA success.

By publishing managed APIs, establishing API manager and publisher roles, extending the governance registry, and offering APIs through an API Store, team have a new opportunity to increase service re-use and enhance IT business value.  For more information on how teams can complement SOA Governance with API Governance, read the promoting services with API Management white paper.

Because services are often imbedded in application solutions, leading Application Services Governance platforms wrap services governance inside application delivery governance. When operation team members use traditional point tools (i.e. Puppet, Chef, Jenkins,Selenium) to achieve DevOps benefits, the teams spend a considerable amount of time and effort creating agile workflow, effective governance, seamless activity transitions, and on-demand self-service access.  A configurable DevOps PaaS can implement governance best practices and be readily adopted by teams without extensive implementation effort.  Effective application delivery governance presents a simplified and unified user experience to complex development tools, processes, and team hand-offs.  By integrating software promotion best practices, test automation, continuous integration, and issue tracking, application delivery governance raises software quality while reducing delivery timeframes.  For more information, read about how to accelerate agility and maintain governance with DevOps PaaS.

Recommended Reading

Policy Management for Application Services Governance

Application Services Governance Requires More Than a SOA Registry

API and SOA Convergence

Promoting services with API Management white paper

Accelerate agility and maintain governance with DevOps PaaS

Governance Registry Brings Integrity to SaaS Platform

Gartner’s analysis of WSO2 SOA Governance

Governance relies on policy, people, process and technology to guide business activity and deliver consistently positive outcomes. Effective governance channels business activity towards the ‘right’ path by making the right actions the path of least resistance.  Policy management is used to specify the correct behavior, detail exception thresholds, and define corrective actions or notifications.  Leading application services governance platforms deliver advanced policy management by conforming to a flexible architecture, covering significant policy categories, and spanning all lifecycle phases.

Flexible policy management architecture enables distribution and separation of policy enforcement points (PEP), policy decision points (PDP), and policy information points (PIP). Additionally, flexible policy management architecture provides self-service access, automates policy decisions, and integrates disparate policy enforcement points.

A complete Application Services Governance Platform covers the following policy categories:

• Design-time Policy
• Run-time Policy
• Security Policy
• Developer access Policy
• Service and API Lifecycle Management Policy
• Application Lifecycle Management Policy

Teams commonly use design-time policies, lifecycle and code time policies, and run-time policies across service, API, and applications.  To reduce ‘policy islands’, a cohesive Application Services Governance platform will provide end-to-end coverage across all lifecycle phases (e.g. plan, design, develop, test, deploy, manage, evaluate, re-use, deprecate, and retire).

Policy Management Architecture

Teams craft policy definitions using policy management interfaces, and the application services governance platform store the policy definitions in policy information points (PIP).  Policy information points are commonly databases, configuration files, or repositories.  Policy enforcement points (PEP) monitor system interactions and compare behavior to policy thresholds.  Policy enforcement points may determine an interaction crosses a policy threshold (e.g. exceeds rate limit, message sent unencrypted, CPU utilization exceeds limit) or delegate the comparison to a policy decision point (PDP).  Policy enforcement points and policy decision points may both take remediation actions. Common policy decision points are SOA governance registries, identity management and entitlement services, authorization servers, and cloud controllers.   Common policy enforcement points are API gateways, mobile gateways, HTTP interceptors, Enterprise Service Bus’ (ESB), or firewalls.

Flexible policy management architecture provides self-service access, automates policy decisions, and integrates policy enforcement points.    When consumers use self-service access and choose their own policy tiers, application service adoption efficiently scales.  Automated policy decisions reduce operations expense and maximize solution consistency.   Integrated policy enforcement points expand policy coverage across the environment and lifecycle phases.

Lifecycle Phases

Teams commonly use design-time policies, lifecycle and code time policies, and run-time policies across services, APIs, and applications.  To reduce ‘policy islands’, a cohesive Application Services Governance platform will provide end-to-end coverage across all solution components and all lifecycle phases (e.g. plan, design, develop, test, deploy, manage, evaluate, re-use, deprecate, retire).

API management portals and SOA Governance Registries must work together to synchronize API and back-end service policies.   Additionally, API lifecycle stages synchronized with backend service implementation stages.  An API Governance experience may provide a straightforward set of lifecycle stages (e.g., created, published, deprecated, retired, blocked) that may be customized by the development team.  SOA Governance Registries facilitates service metadata management and governance across design, implementation, test, and run-time operations.  Figure 1 below depicts the intersection of the API governance and service governance views.

Figure 1: API Governance and Service Governance Views

Application delivery governance requires a unique set of promotion and demotion policies tied to funding, design reviews, security reviews, and test results.   Application Services Governance Platforms should span project inception, development, quality assurance, production deployment, production management, maintenance, and retirement.  Figure 2 illustrates service implementation activities governed by application delivery governance.

Figure 2: Implementation activities governed by application services delivery governance

Policy Management Categories

A complete Application Services Governance Platform manages, stores, decides, and enforces:

• Design-time Policy
• Run-time Policy
• Security Policy
• Developer access Policy
• Service and API Lifecycle Management Policy
• Application Delivery Management Policy

Figure 3. Application Services Governance Policy Categories

Design-Time Policy Management and Enforcement

Design-time polices ensure:

• Developers use a common naming convention for artifacts
• Enforcement of standards (e.g.: schema standards, namespace naming conventions and interoperability validation across services)
• Service and API versioning (e.g.: version numbering policies, policies for creating/approving new versions, revisions and restoration policies)
• WS-I Compliance
  • Basic Profile (BP)
  • Simple SOAP Binding Profile (SSBP)
  • Attachments Profile (AP)
  • Basic Security Profile (BSP)
  • Lifecycle promotion policies via checklist/policy enforcement
  • Project teams publish their services in the repository
  • WSDL and XML Schema validation

Run-time Policy Management

A complete Application Services Governance platform governs and manages the following run-time policy categories:

Service Level Agreement Monitoring & Reporting

○      Tenant and subscriber rate limiting

○      Service-aware and tenant-aware load balancing policies

○      Private tenant partitions to reduce ‘noisy neighbor’ impact

○      Trigger notifications based on service usage thresholds

Billing and metering policies

○      Rate limiting service and API interactions

○      Throttle service and API interactions

Entitlement and Authorization via XACML, e.g., who can access which service, API, application, or resource for what purpose

○      WS-SecurityPolicy enforcement

○      Throttling maximum connections to systems via policy

○      Caching responses via policy

○      Attribute-based access control

○      Role-based access control

Infrastructure Provisioning

○      Define and enforce auto-scale limits.  Infrastructure resource pool constrained between minimum and maximum run-time instance thresholds

○      Limit provisioning administration activity based on permission policies assign to user role

Service mediation policies

Using a zero coding approach and only policy/rule authoring and configuration, teams may define policies that:

○      Automate routing of messages based on content-based rules: i.e. send alerts for all orders where the order value is greater than the customer’s credit limit.

○      Turn off services or reroute based on time of day or other aspects.

○      Transform message format

Security Policy Management and Enforcement

Beyond basic authorization and authentication, a comprehensive Application Services Governance Platform supports API subscription approval policies and API token expiration policies.  Role-based access control (RBAC) and fine-grained entitlement based access control policies may be associated with users, services, and APIs.  Attribute or Claim based access control is available via XACML, WS-Trust, or OpenID. Security policies may be attached to services, APIs, or resources.

Developer Access Provisioning Policies

Developer subscription, usage, and access may be managed and governed.  Developer self-service subscription policies may capture developer information and trigger approval workflow.  Role-based access controls may be applied to developer provisioning.  The Application Services Governance Platform should support multiple roles (e.g. API creator, API publisher, and API subscriber).

Service and API Lifecycle Management Policies

Teams may define custom gates and checklist items to govern and manage the service and API lifecycle processes. Lifecycle stages and stage transition policies may be defined and extended by administrators. Approval policies (supports multiple approvers) can be setup to control stage transitions.

In addition to checklist/approval based manual lifecycle governance policies, users can establish automated validation rules (using pre-built validators or custom Java-based validators) and define lightweight WS-HumanTask based process workflows or complete BPEL business process orchestration.

Application Delivery Management Policies

Web services and Web APIs are just one type of solution artifact that should be managed by the governance platform.   Teams must also govern and manage application lifecycle promotion and versioning.  Development teams may define custom gates, checklist items, and promotion/demotion rules to govern and manage application lifecycle processes.

Common Policy Management Scenarios

Teams commonly implement the following design-time, service and API lifecycle management, and run-time policies.

Common Design-Time Policies

The platform’s governance registry user interfaces commonly manage and govern WSDL validation, WS-I compliance, and XSD reuse.  Complementary API Manager user interfaces manage and govern API subscriptions and API promotion meta-data.  API promotion meta-data includes keyword tags used to categorize APIs, developer documentation used to help developers evaluate APIs.  Both service and API views enforce design-time checkpoints to ensure adequate documentation and promotion meta-data is defined before publication.  Subscription and usage reports help teams understand API adoption (by version, by API) and usage (by version, by API).  By understanding API adoption and usage, API business owners and API architects can intelligently invest future development resources, properly plan API infrastructure scale, and rationalize the API portfolio

Common Service and API Lifecycle management Policies

Teams using a governance registry (for services), API developer portals (for APIs), and project development interface (for service implementation projects) commonly utilize lifecycle management policies that include versioning schemes, promotion approval authority, and checklist conditions that must be passed before promotion.  During demotion, the reason is captured and workflow triggered to rectify open issues.

Common Runtime Policies

In conjunction with message intermediary enforcement points (i.e. ESB and gateway proxies) and identity entitlement decision services, an Application Services Governance Platform is commonly used for service response caching, service throttling, service load-balancing, and XACML-based access control.

Sample Governance Model

Within these three broad categories (i.e. design-time, lifecycle-time, run-time), teams may configure advanced policy decisions and enforcement. The Application Services Governance Platform should support defining high-level service descriptions independent of low-level service definitions.  The following best-practice end-to-end service governance model is recommended:

1. Build a namespace/organizational hierarchy that correctly defines the business areas.

2.    Business analysts use the service definition interface to create a set of high-level service definitions that map to the eventual model

3.    Using Eclipse modeling technology or third-party tools, teams may build a canonical data model using XSD.

4.    A governance registry helps maintain the consistency of this by finding shared schemas across services and notifying when changed.

5.    As services are refined to create real WSDLs or technical definitions tie these to the high-level service descriptions.

6.    The governance registry should automatically catalogues WSDLs in the correct namespace hierarchy.

7.    Application Services Governance Platform Dashboards provide an overview of the state of services, the number of services, the lifecycle stages of services, schema re-use and other overview to understand the overall progress.

Recommended Reading

Policy Management Requires More Than a SOA Registry

Application Services Governance

Governance Registry Brings Integrity to SaaS Platform

Gartner’s analysis of WSO2 SOA Governance

API and SOA Convergence

After understanding a project’s capabilities and roadmap, anyone is able to start directly hacking the source code and contributing useful extensions. Because open source is a distributed, participatory meritocracy, the upside benefit is high and the barrier to entry is low—you don’t have to move, be employed by a Valley startup, give up your day job, or wait to obtain a 4 years for a degree.

Over on opensource.com, I have published an article describing 10 Ways to Participate in Open Source.      If you want to hear the webinar presentation, register at the WSO2 site.

Cloud’s on-demand self-service and ticketless IT processes drastically reduce time to provision IT resources. APIs and cloud infrastructure services serve as composable building blocks, enabling solution adaptation on opportunity context.  For example, a bank can re-use bank services in a new market and plug-in local regulations.

DevOps PaaS delivers an approved, low cost development, deployment, and maintenance cost structure.   IT efficiently supports the long tail of user strategy and priorities, and business needs are met by a timely and cost-efficient IT solution.  Shadow IT is embraced and enabled within the IT structure rather than being excluded and repressed.

When everyone is on the same team, participation is encouraged and the team scales to meet business demand. When extending the IT team with business analysts, power-users, out-sourced teams, and contractors, a responsive IT structure consistently and automatically enforces compliance and governance policies.

The path to Responsive IT requires moving away from traditional application platforms, traditional team structure, and traditional information flows.  Responsive IT teams are adapting their infrastructure, processes and tooling to re-invent the application platform and re-think application delivery.  The New IT architecture underlying Responsive IT intelligently incorporates Cloud Platforms, BigData Analytics, Enterprise DevOps, and API first development.

The Path to Responsive IT white paper provides a roadmap plan.

Recommended Reading

Accelerating Business Agility with App Factory DevOps PaaS

What is an API Management Platform?

Both API and SOA success requires creating loosely coupled consumer-provider connections, enforcing a separation of concerns between consumer and provider, and exposing a set of re-usable, shared services, and gaining service consumer adoption.   With traditional SOA, many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams.

Over a period of six years (i.e. 2003-2009), I consulted and advised over 200 large enterprise IT organizations on how to create effective SOA strategy and SOA roadmaps.  The experience provided a battle-tested SOA strategy for moving organizations forward.  After performing a SOA portfolio review and understanding their maturity, many teams were overwhelmed by the amount of IT transformation required to implement an effective SOA initiative.   All teams gained small and localized benefit by implementing ‘service oriented integration’ and web services, yet many struggled to establish a coherent architecture.

In today’s connected business world, API and SOA are the business.   How do we deliver the technology the business wants and accelerate business agility?  An effective approach must address human collaboration stumbling blocks.

Kin Lane posted a provocative and philosophical article describing “SOA vs. API: The Humans Win.”   Kin states an API focus is more effective than traditional SOA because they focus on the human side of endpoint consumption. According to Kin,

SOA …doesn’t always provide for the best interest of the user–aka human side of the equation. APIs have allowed for valuable resources to flow around traditional IT bottlenecks, outside the firewall and be put to use by those who are potentially closer to the human problem that is being solved.

Kin describes how common API attributes complement SOA by providing important SOA puzzle pieces:

API introduces newer pieces of the SOA puzzle, found within the OAuth security relationship, terms of use and privacy policies, self-service access, transparency, while also providing monetization strategies that encourage partner and developer innovation.

The real insight in Kin’s post:  API and SOA fit together, and API management can be used to advance SOA initiatives.  API management complements SOA Governance, drives service reuse, and maximizes Service Oriented Architecture success.  Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams. SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. Too often, there is little or no insight into service reuse and:

• How to enable business functionality as an API
• Who is writing re-usable APIs and services
• Who is consuming APIs and services
• How APIs and services are being used

A recent blog post and white paper describes how API management complements SOA initiatives by overcoming traditional SOA implementation limitations.

Software architects and developers can take five actions to avoid common API and SOA pitfalls, create business value, and monetize API assets:

1. Embrace the Managed API
2. Establish a Monetization Model
3. Make APIs Easy for Developers to Access
4. Employ Governance
5. Monitor API Use

How are you making your SOA initiative a success?

Queuing, waiting, and the status quo doesn’t fit well with today’s “now generation’.  Business stakeholders, who drive revenue growth and customer retention, desire to rapidly seize opportunity and market share.  They often view IT timeframes and capabilities as a poor match for today’s fast business-pace.  A New IT model is required to reduce delivery time and accelerate business agility.  DevOps PaaS brings no waits, faster phase execution, widespread accessibility, rapid grassroots innovation, and increased resource availability to IT projects.

As the pace of business quickens, mismatched IT delivery cycle periods decrease business satisfaction and revenue growth.  We live today in a ‘now generation’, where individuals expect instant gratification and action.   Even the Black Eyed Peas recognize today’s business growth imperative and IT customer demands:

I want it now

Big money, give me mo’ money

Yeah, I want it now

I need cash, oh, I need it bad

I want it now

The Peas also underscore how stakeholders pressured to grow the business today will be irked by misaligned delivery timeframes:

Cause if time can’t wait

Then I sure can’t wait

I ain’t got no patience

No, I just can’t wait, not today

For more pop inspiration, read the full BLACK EYED PEAS – NOW GENERATION LYRICS and watch the video.

In 2011, Gartner presaged the ‘now generation’ sentiment and consumerized IT ownership shift we see today in their Top Predictions for 2012 and Beyond report:

Next generation digital enterprises are being driven by a new wave of business managers and individual employees who no longer need technology to be contextualized for them by an IT department. These people are demanding control over the IT expenditure required to evolve the organization within the confines of their roles and responsibilities. CIOs will see some of their current budget simply reallocated to other areas of the business. In other cases, IT projects will be redefined as business projects with line-of-business managers in control.

You and your team probably feel mounting demands and pressure to clear a backlog of project requests.   You have gained agility benefits by adopting Agile and Iterative development methods, but have experienced a bottleneck when Agile’s fast pace clashes with systems administration and provisioning.  Agile and DevOps principles must be applied across a cross-functional team and the entire lifecycle (e.g. project inception, design, development, deployment, and management).

When defining a roadmap to align IT’s pace with business agility expectations, establish IT team objectives that quicken IT solution development and delivery, offer new technology as on-demand shared services, and enhance your team’s ability to rapidly satisfy emerging business use cases (e.g. social collaboration, mobile application connectivity, ecosystem partnering).

Adopting a DevOps PaaS can align your IT model with business agility expectations.

How DevOps and PaaS influence Business Agility

DevOps principles and practices combined with PaaS characteristics will quicken IT solution development and delivery.   A DevOps focus on continuous activity execution (e.g. continuous build, continuous integration, continuous test, continuous delivery) creates a ‘no wait’ environment.   Teams do not have to wait for the next script to run or for the next activity to commence.  By incorporating automation into developer and operations processes, teams bypass time consuming manual tasks and gain faster phase execution.  Both DevOps and PaaS promote simple, on-demand self-service environments that shield team members from complexity and reduce skill hurdles.  By offering on-demand self-service access, rapid business innovation and experimentation is possible. By reducing complexity, team members are not required to obtain special training and skills before consuming IT services and infrastructure.

PaaS increases agility by democratizing access to IT infrastructure and services.  Offering a low cost environment and increasing resource availability, PaaS promotes democratized access.   The chosen PaaS environments must offer required application building blocks available on-demand, and minimize cost by amortizing infrastructure expense over multiple project teams.   PaaS environments based on multi-tenant, shared application containers facilitate pervasive access by increasing tenant density and lowering tenant cost.   Affordable, pervasive on-demand access encourages project teams to use approved PaaS environments and enables shadow IT teams to efficiently and safely create a long tail of application development projects.

Quantifying Agility

In the abstract, business agility can be defined as your ability to rapidly change business vectors. A business vector is your business speed and direction.  The direction may lead into new markets and new products, or engaging with new participants.  Reducing time to IT solution delivery increases your team’s ability to adjust the business vector and match business opportunity.

With adequate instrumentation, IT delivery agility can be quantified.  Consider the following agility metric recommendations:

• Time to create project workspace

• Time to build, integrate, test

• Time to approve, promote

• Time to deploy, release

• Dwell time – time waiting for the next operation to commence or complete

After application project inception and before coding commences, systems administrators must create project workspaces.   How long does your team wait before gaining access to source code management repositories, requirement management projects, and defect tracking projects?

Moving code through build, integration, and test tools is often a time and labor-intensive process.  The entire team waits while applications assets are built, integrated, and tested.  When teams use iterative development processes, the wait time aggregates over several hundred or thousands cycles.  How long does your team wait during build, integration, and test phases?

When one team member finishes a task and the work enters an approval phase, how long does the team wait?  After the work is approved to move through phase gate, how long before the project is promoted into the next phase?

Operations activities related to deployment and release management often hinders agility and time-to-market.   The level of effort required to deploy a real-world application is often non-trivial.  Continuous deployment technology automates operations activities and replaces manual intervention.

While dwell time sounds cozy and refreshing, excessive wait states and downtime between activities diminishes team efficiency and engagement.  Automated notifications eliminate dwell time between hand-offs.  Automated project workspace creation, Cloud environment provisioning, and on-demand self-service access reduces wait time between software development phases.

How AppFactory DevOps PaaS Accelerates Business Agility

A DevOps PaaS incorporates DevOps principles and practices into a Platform as a Service environment.  DevOps principles include iterative cycles, continuous activities (e.g. build, integration, test, delivery), automated processes, self-service IT, on-demand access, collaborative interactions, and incremental releases,  .

When operation team members use traditional point tools (i.e. Puppet, Chef, Jenkins, Selenium) to achieve DevOps benefits, the teams spend a considerable amount of time and effort creating agile workflow, effective governance, seamless activity transitions, and on-demand self-service access.  WSO2 App Factory delivers a configurable DevOps PaaS that can be readily adopted by teams without extensive implementation effort.  WSO2 App Factory presents a simplified and unified user experience to complex development tools, processes, and team hand-offs.  By integrating software promotion best practices, test automation, continuous integration, and issue tracking, App Factory raises software quality while reducing delivery timeframes.  Figure 1 illustrates the holistic lifecycle approach delivered by a DevOps PaaS.

Figure 1.  DevOps PaaS Process Activities

Traditional application PaaS (aPaaS) environments do not help organizations build apps, but simply serve as a cloud run-time environment.  DevOps PaaS delivers development, test, and production run-time clouds that are integrated into development workspaces containing source code management, defect tracking, requirements management, test automation frameworks, and continuous build.  Figure 2 describes the infrastructure topology underlying a DevOps PaaS.

Figure 2. DevOps PaaS Infrastructure Topology

By automating software activities, workflow, and phase approval gates, a DevOps PaaS decreases software development and delivery times.   A rapid IT timeframe closely matching today’s fast business-pace will accelerate revenue growth and enhance customer retention rates.  A New IT model driven by DevOps PaaS will expand development team participation, lower IT cost, and increase business agility.

Recommended Reading

DevOps Meets ALM in the Cloud

PaaS Performance Metrics

Multi-tenant, shared container PaaS TCO

WSO2 App Factory Product Page

PaaS offerings could easily extend and provide developer-friendly application platform services via consumable APIs; subsuming today’s BaaS value proposition.   As mobile application use cases collide with mission-critical enterprise requirements, developers will require more extensive platform capabilities, which are not delivered by BaaS today.   PaaS services deliver application platform capabilities required when building sophisticated applications.  For example, a BaaS offering billing, security, and data storage services today must evolve to offer messaging, registry, logging, and task management.  Figure 1 describes a few sample foundation services.  Additionally, leading PaaS environments offer application platform middleware services that span identity management, application lifecycle governance, integration, and custom code hosting (within app, service, process, rules, and data containers).

Figure 1.  Platform as a Service Reference Architecture and PaaS Services Layer

When the moderator, Kin Lane, asked the panel about their views regarding unique value proposition, a few participants mentioned ‘hosting custom code’.   My attention raised an order of magnitude!   Hosting custom code is the fundamental PaaS differentiator from IaaS (hosts servers) and SaaS (hosts configurations).

In a recent blog post, Toddy Mladenov brings an interesting perspective to the PaaS/BaaS value proposition:

 More than decade ago the application servers advanced the way new applications are developed by offering common framework and set of reusable components. Platforms-as-a-Service are the next step in the evolution of application development

As the underlying application platform evolves into PaaS, the innovator dilemma is unfolding and market disruption is occurring. The new school BaaS vendors are riding the mobile trend while delivering a useful toolbox for overcoming mobile application development hurdles.  Yet BaaS offerings are hitting a wall by offering a closed set of backend application services.  Innovative Public and Private PaaS vendors (e.g. Apprenda, Heroku, WSO2) are challenging established vendors (e.g. Oracle, IBM, Red Hat) as the preferred platform when forklifting web applications or building new cloud-aware applications.

As PaaS innovators focus on increasing application development agility, reducing time to market, and lowering backend skill hurdles, the line between PaaS Services and BaaS Services will blur.  The end goal is to deliver an open, extensible PaaS where developers can easily weave APIs, services, processes, data, and user interface widgets into a compelling user experience.

A first pass simply collates search referral terms and does not normalize the list by search referral count.   A visitor search for PaaS 50 times is counted equally as a search for SOA five times.   In the tag cloud, the tag size for the search term indicates how many times the keyword is used in combination with other search term modifiers.  For example,  PaaS architecture, PaaS TCO, and DevOps PaaS.   Figure 1 below illustrates the search term distribution:

Across all search term phrases, the tag cloud identifies the following common terms: ‘API’, ‘architecture’, ‘cloud’, ‘Enterprise Service Bus’, ‘ESB’, ‘paas’, ‘products’, and ‘vs WSO2′.

I used wordle.net to generate a tag cloud by evaluating keyword distribution across the cobiacomm RSS feed.  A first pass limitation, the RSS feed only feeds blog post excerpt text up to the ‘read more…’ section break.   Figure 2. below presents a tag cloud illustring keyword distribution across the cobiacomm RSS feed.

In the excerpt text, the blog post content demonstrates a focus on ‘architecture’, ‘application’, ‘business’, ‘cloud’, ‘open’, ‘platform’, ‘PaaS’, ‘source’, and ‘WSO2′.

Next pass will be to analyze full blog post content and properly weight referral search terms by term count.

Interacting with open source community committers and recommending source code hacks is a valuable experience.   During 2001-2003, I had the opportunity to interact with many hard-core, professional open source luminaries (e.g. Sam Ruby, James Snell, Glenn Daniels, Dims, Steve Loughran, and Sanjiva Weerawarana) across multiple organizations while participating in the Apache Axis project.  I watched the distributed Axis team advance the project via IRC, code check-ins, and mailing list interactions.  After understanding the project’s capabilities and roadmap (by writing many sample code service clients and providers), I gained the knowledge to start directly hacking the source code and contributing useful extensions.   My everlasting thanks to Glenn Daniels for nominating me to be a committer!  The open source community and committer experience established my open source street creds, raised my personal brand,  led to presenting from the OSCON stage (and others), and helped build my consulting business.

My Apache Axis participation (as an independent XML web services consultant) a decade ago has introduced me to many helpful individuals (e.g. Anne Thomas Manes, Michele Leroux Bustamante, and Burr Sutter ) and opened many opportunities.  With the upside so high and barrier to entry low (don’t have to move, be employed by a Valley startup, give up your day job, or wait for a 4 years for a degree), I wonder why more open source users do not actively participate in the open source community and become  committers or contributors.

Today’s open source is competitive (or even more advanced than) with proprietary software, and delivered without proprietary handcuffs.  By integrating and enhancing leading, best-of-breed open source projects, WSO2 extends Apache projects (and other leading OSS projects not hosted in Apache) into a comprehensive cloud platform.   The WSO2 Apache Way web page lists key embedded projects, and the impressive list of WSO2 individuals who are Apache committers.  By building on external open source projects, WSO2 is able to interact with the innovative thought leaders from Twitter, FaceBook, Google, IBM, Red Hat, and Netflix to advance open source value.

 Call To Action

Donnie Berkholz at RedMonk has a good blog post describing How to recruit open-source contributors.    I am following Donnie Berkholz‘s advice and reaching out to request your participation as we take the most complete and composable open source WSO2 Carbon platform to the next level.

Has your team built any platform, management or framework code that you would like to see directly incorporated into WSO2 Carbon? Are you a GitHub project owner and your code could enhance the WSO2 platform and be helpful to thousands of WSO2 users?

We welcome your participation in the WSO2 and Apache open source community!  Contact us today to explore community involvement opportunities and contributions.

Pragmatic Recommendations On How To Get Started with Open Source Community Participation

Jeremy Mikola has shared a slide deck describing on how to be a good OSS contributor.  A good way to start is by subscribing to WSO2 architecture mailing lists and digging into the sample code.  Daniel Doubrovkine has compiled a list of qualities that will make you an amazing contributor:

1. Have a real problem to solve, business need, or some type of commercially-driven motivation.

2. Understand the goals of the project and make sure your contribution is in line with them.

3. Submit complete patches that implement full features. Include any test information and documentation.

4. Play by the rules of the project that you’re contributing to.

5. Be humble. Never add your name to the list of contributors yourself—the project leader should do so, if she or he values your work.

6. Have low expectations. Learn to accept rejection.

7. Persevere. Improve upon comments and keep sending updates.

8. Be honest and vocal about your available time and skills.

9. Be a doer, not a talker or a troll.

10. Finish what you started, don’t give up.

Other less code-intensive contribution opportunities exist. You may be more confortable contributing documentation, blog posts, and presentations. Barbara Shuarette shares a contribution list at opensource.com.

Recommended Reading

10 Ways to Participate In Open Source

The abstract for the presentation:

Offering a business capability as a one-size-fits-one solution is a typical IT solution trap. One-size-fits-one solutions do not exhibit the adaptability or agility required to fulfill new business opportunities. Teams are intrigued by the cloud’s promise to create a one-size-fits-ALL solution. Implementing Cloud architecture concepts to build an ecosystem platform and a vertical Platform-as-a-Service (PaaS) will accelerate the IT team’s ability to deliver solutions that support business growth objectives. A cloud ecosystem platform enables teams to deploy context-aware solutions, rapidly provision 3rd party application projects, automate governance approval tasks, ensure regulatory compliance, monetize user interactions, and host applications that seamlessly extend the user experience. By hosting all business partners as tenant applications within a multi-tenant environment, the ecosystem environment more readily aggregate and share business information.

In this session, Chris will describe:

• Why ecosystem platforms and tenant personalization increase business agility.

• When to extend the user experience by architecting multi-tenant, context-aware cloud applications and APIs.

• How frameworks and containers are evolving to deliver a multi-tenant environment from data to screen.

• How a vertical Platform-as-a-Service ensures regulatory compliance, automates governance approval tasks, and more readily shares business information and capabilities.