Enterprise Architecture Practice - Capabilities

Enterprise Architecture (EA) function now have an unprecedented chance to lead the way in identifying new business opportunities, thanks to the innovations in the web and mobile technologies and businesses realizing the business advantages of such advancements. EA serves a strategic business purpose by enabling business capabilities to be implemented via IT architecture and related IT delivery processes.

Though Enterprise Architecture is not a very new practice, the maturity level is still not the optimal in most enterprises. Seeing the benefits that the EA function can bring to the table,  many enterprises are attempting to setup the EA practice within, but are in fact struggling to get it right. EA not just science and not just art as well. It is a combination of art and science. Successful EA practice has been found to being able to demonstrate certain key capabilities. In the EA world, there is no such thing as 'one size fits all', as it is highly dependent on the enterprises' business, its objectives, goals, strategies and priorities, which is never the same across enterprises.

While the objective of this blog is to discuss about the key capabilities that the EA function should be able to demonstrate, it is also good to highlight out what EA is not.

What EA is not:

• EA is NOT a project
• EA is NOT about review 
• EA is NOT a one-time activity
• EA is NOT for IT
• EA is NOT a strategy
• EA is NOT all about cost-reduction
• EA is NOT one-man show

A successful EA practice should consider practicing and demonstrating the following key capabilities:

Staying Relevant

As we all know, it is highly unlikely that an architectural solution that works well for one enterprise will work well for another in the same industry domain. This is because each enterprise has its own vision and mission to win over the competition and constantly wish to stand alone in the crowd in certain key areas. Staying relevant helps the EA function in aligning strategic and operational views of business with the underlying technology and service delivery processes. For this reason, the EA practice should strive to understand the vision, mission and strategies of the enterprise and continue to stay aligned to the same, so that the architectural solutions continue to stay relevant for the enterprise.

Technology & Architecture Vision

No doubt that modern enterprise largely depend on technology and in certain cases, the business in fact is driven by technology. Irrespective of whether technology drives the business or not, technology is a key enabler of the business. So, it becomes essential to have a technology vision, which is aligned to the business vision. It is needless to mention that having a vision will not be just enough, and the same shall be driven down to the operational processes and practices. Every architecture and governance process should derive the technology vision as envisaged and so the solutions continue to stay relevant and yield the intended results. The technology vision and strategy shall be such that leverages both new tech innovations and existing capabilities that will enable the business to achieve the target state. 

The goal of the architecture vision is to articulate how the proposed architecture will enable the business goals, respond to the strategic drivers, conform to the principles, and addresses the stakeholder concerns and objectives.

Transforming and automating operations

While leveraging the existing knowledge and resources is key in saving costs, it is important for the EA function to stay on top of the technology and business innovations and explore opportunities of leveraging the same so that the enterprise stays on course of achieving its target mission and vision. This is where the EA teams should consider leveraging Agile approaches, so that the target reference architecture also stays dynamic and relevant. The EA framework shall have an evolution cycle, so as to improve the framework itself and similarly the architecture solutions should also be continually evolved based on feedback and availability of enabling technologies and innovations.

It is needless to mention here that the EA function shall equally consider the 'Business As Usual' as any transformational initiative should not derail the enterprise from achieving its intended mission and vision.

Being the Change Leader

EA is all about bringing change for the good. i.e. EA programs is all about driving the enterprise from its current state to the target reference state, which is nothing but identifying and driving changes to various resources at various levels, so that the target state is achieved. This is yet another key capability that come down to the old adage of building “better, faster, cheaper” systems that provide agility to change or expand capabilities, in response to ever-changing business requirements. EA function leads the planning for these new system and technology capabilities, ensuring the best solutions to the business requirements by providing blueprints and implementation road maps to the design and delivery teams. They also provide a service to the other organizational functions by ensuring compliance of these solutions at critical design and delivery milestones.

Mitigating risk

As the emphasis shifts from cleaning up the legacy of systems and technologies to better planning and governance of new IS and IT initiatives, we see a corresponding shift in the role of the EA practice. The focus shifts from driving out costs to reducing risks associated with new programs, while ensuring timely delivery of new capabilities. 

Every architectural initiatives shall be subject to a risk review and decisions shall be made based on the business value expected out of it. The changing business and regulatory conditions might also impact the solutions and at times could end up the enterprises not being able to realize the intended value out of it. This where the "Fail Fast" approach would help in making the right decisions. Periodic reviews of the change or transformational projects should be conducted with a view to ascertain whether the intended value is not impacted with the current conditions. Thus being able to manage and mitigate the risks well is a key capability that the EA practice should demonstrate.

Overseeing investments

It is natural for enterprises to look for Return on Investments (RoI), as the capital has a cost. The EA practice shall consider the cost of capital and the investment requirements for various change initiatives and work with the related other functions to ensure that the benefits are quantified so as to ensure the investments yield desired returns. In cases where the benefits are not directly quantifiable, the EA team shall identify such indirect benefits derived out of such investments and shall ascertain the monetary value in a best possible manner. 

Governing the architecture

As said earlier, EA function is not a project and it is a continuous function. EA function shall put in place necessary framework to monitor and manage the architectural activities in a constant basis. Business architects in the EA function monitor the project portfolio, while IT architects govern technology solutions, leveraging reference architectures to build the future state in alignment with strategic road maps. The governance principles shall be applied to various architecture activities with an objective to ensure the strategy alignment, risk management, measuring & monitoring, optimal resource utilization.

Integrating people, processes, and technology

Considering the innovation around the areas of web, mobile, big data powered by social media, modern enterprises are looking forward to leverage these to derive maximum business value. In this direction, to stay competitive and relevant to the customer business, most successful organizations are rapidly moving towards the system of engagement architecture supported by digital collaboration platforms and social strategies devised by EA where EA would create an effective social governance model and an overall enterprise strategy. It necessitates a pervasive social layer that spans many different system of records and departments within an organization. Discussion would also enlighten more focus on expanding social footprint by delivering consistent digital experience and utilizing social content and online communities to increase collaboration with customers and other stakeholders.

Principles of Information Governance

With the evolution of tools and technologies around big data, the variety and volume of customer information collected has increased many fold. This also requires the responsible use of such information by the organization. Many countries have promulgated legislations to regulate the use and protection of such information in every organization.

The set of multi-disciplinary structures, policies, processes and controls that are used to manage the customer information and thereby supporting the current and future reglatory, legal and operational requirements make up the Information Governance framework of the organization. Information governance goes beyond retention and disposition to include privacy, access controls, and other compliance issues. It is interesting to note that big data innovators recognize the importance of governance to the success of their projects.

The Principles identify the critical hallmarks of information governance and provide both a standard of conduct for governing information and metrics by which to judge that conduct. In doing so, they give assurance to the public and society at large that organizations of every kind are meeting their responsibilities with respect to the governance of information.

Transmational organizations looking forward to demonstrate the highest level of maturity in the Information Governance design their Governance framework based on the following key principles:

Accountability:

Accountability to is key for the success of any program and on the same lines, for the Information Governance, to be successfull shall have an accountable senior leader, who shall oversee the governance practices and should require regular reporting for monitoring purposes. The organization should adopt policies and procedures to guide its workforce and agents and ensure its program can be audited and continually improved to support the organization’s goals.

An information governance program should at the minimum:

• Establish an information governance structure for program development and implementation
• Designate a qualified accountable person to develop and implement the program
• Document and approve policies and procedures to guide its implementation
• Remediate identified issues
• Enable auditing as a means of demonstrating the organization is meeting its obligations to both internal and external parties

A high maturity organization would demonstrate the following:

• The organization’s senior management and its governing board place great emphasis on the importance of information governance. 
• The records manager directs the records management program and reports to an individual in the senior level of management. 
• The chief information governance officer and the records manager are essential members of the organization’s governing body. 
• The organization’s initial goals related to accountability have been met, and it has an established process to ensure its goals for accountability are routinely reviewed and revised. 

Transparency

An organization’s processes and activities relating to information governance shall be documented in an open and verifiable manner. Documentation shall be available to the organization’s workforce and other appropriate interested parties within any legal or regulatory limitations, and consistent with the organization’s business needs. Transparency of the organization’s governance practices must extend to definitions of appropriate information uses and the processes for ensuring compliance with policies on appropriate information use.

An information governance program includes its information management and information control policies and procedures. To ensure the confidence of interested parties, records documenting the information governance program must themselves adhere to the fundamentals of information management.

At the highest maturity level, an organization should practice and demonstrate the following:

• The organization’s senior management considers transparency as a key component of information governance. 
• The software tools that are in place assist in transparency. 
• Requestors, courts, and other legitimately interested parties are consistently satisfied with the transparency of the processes and the organization’s responses. 
• The organization’s initial goals related to transparency have been met, and it has an established process to ensure its goals for transparency are routinely reviewed and revised. 

Integrity

An information governance program shall be constructed so the information generated by or managed for the organization has a reasonable and suitable guarantee of authenticity and reliability. Integrity of information, which is expected by patients, consumers, stakeholders, and other interested parties such as investors and regulatory agencies, is directly related to the organization’s ability to prove that information is authentic, timely, accurate, and complete. For the healthcare industry, these dimensions of integrity are essential to ensuring trust in information.

For safety, quality of care, and compliance with applicable voluntary, regulatory and legal requirements, integrity of information should include at least the following considerations:

• Adherence to the organization’s policies and procedures
• Appropriate workforce training on information management and governance
• Reliability of information
• Admissibility of records for litigation purposes
• Acceptable audit trails
• Reliability of systems that control information

Transformational organizations, which are at the highest maturity level should demonstrate the following abilities:

• There is a formal, defined process for introducing new record-generating systems, capturing their metadata, and meeting other authenticity requirements, including chain of custody. 
• Integrity controls of records and information are reliably and systematically audited. 
• The organization’s initial goals related to integrity have been met, and it has an established process to ensure its goals for integrity are routinely reviewed and revised. 

Protection

An information governance program shall be constructed to ensure a reasonable level of protection to records and information that are private, confidential, privileged, secret, classified, essential to business continuity, or that otherwise require protection.

Information protection takes multiple forms. First, each system must enable management of security access controls. Only members of the workforce and other authorized parties with the appropriate levels of access or security clearance may access information relevant to their roles or duties. Reliably protecting electronic and physical assets requires use of tools such as user authentication, key card access restrictions, and other relevant measures. This also requires that as the workforce and other authorized parties transition in status or job function, respective level of access is changed immediately to a level appropriate to the new role and duties.

The highly matured organizations would practice and demonstrate the following:

• Executives and/or senior management and other governing bodies (e.g., board of directors) place great value in the protection of information. 
• Audit information is regularly examined, and continuous improvement is undertaken. 
• Inappropriate or inadvertent information disclosure or loss incidents are rare. 
• The organization’s initial goals related to protection have been met, and it has an established process to ensure its goals for protection are routinely reviewed and revised. 

Compliance

An information governance program shall be constructed to comply with applicable laws and other
binding authorities, as well as with the organization’s policies. Every organization should:
Know what information should be entered into its records to demonstrate its activities are being conducted in a lawful manner.

Enter that information into its records in a manner consistent with laws and regulations.
Maintain its information in the manner and for the time prescribed by law or organizational policy.
Develop internal controls to monitor adherence to rules, regulations, and program requirements, thus assessing and ensuring compliance.

The following capabilities when demonstrated will mark the highest maturity level:

• The importance of compliance and the role of records and information in it are clearly recognized at the senior management and governing body levels.
• Auditing and continuous improvement processes are well-established and monitored by senior management. 
• The roles and processes for information management and discovery are integrated, and those processes are well-developed and effective. 
• The organization suffers few or no adverse consequences based on information governance and compliance failures. 
• The organization’s initial goals related to compliance have been met, and it has an established process to ensure its goals for compliance are routinely reviewed and revised. 

Availability

An organization shall maintain records and information in a manner that ensures timely, efficient, and accurate retrieval of needed information.

A successful and responsible organization must have the ability to identify, locate, and retrieve the information required to support its ongoing activities. This information may be used by:

• The healthcare team, patients, and other caregivers Authorized members of the workforce and others authorized consistent with regulations 
• Legal and compliance authorities for discovery and regulatory review purposes
• Internal and external reviewers for purposes including but not limited to: payer audit, financial audit, case management, and quality assurance.

High maturity organizations practice and demonstrate the following:

• The senior management and governing body provide support to continually upgrade the processes that affect records and information availability. 
• There is an organized training and continuous improvement program across the organization. 
• There is a measurable return on investment to the organization as a result of records and information availability. 
• The organization’s initial goals related to availability have been met, and it has an established process to ensure its goals for availability are routinely reviewed and revised. 

Retention

An organization shall maintain its records and information for an appropriate time, taking into account its legal, regulatory, fiscal, operational, and historical requirements.

As part of its retention program, an organization must develop an information retention schedule, which specifies what information must be retained and for what length of time. Retention decisions are based on the type of information, and the organization’s legal, regulatory, fiscal, operational, clinical, role/mission, and historical requirements. Information retention schedules should be reviewed periodically and revised regularly. Some internal changes in the organization such as mergers and acquisitions or lines of business changes, or types of records generated, as well as external events such as legal, regulatory, or fiscal changes, may require revisions.

High maturity organizations consider practising the following:

• Retention is an important item at the senior management and governing body level.
• Retention is looked at holistically and is applied to all information in an organization, not just to official records. 
• Information is consistently retained for appropriate periods of time. 
• The organization’s initial goals related to retention have been met, and it has an established process to ensure its goals for retention are routinely reviewed and revised. 

Disposition

An organization shall provide secure and appropriate disposition for records and information that are no longer required to be maintained by applicable laws and the organization’s policies.

Disposition includes not only destruction, but also any permanent change in custodianship of the information, such as when it is transferred to another party due to a merger or acquisition of another hospital, clinic, or physician practice or when a organization discontinues a practice, service, or other business. In many cases, the appropriate disposition is the destruction of information, in which case the organization should ensure the information is transported and destroyed in a secure and environmentally responsible manner. The organization should document or certify that the information has been destroyed completely and irreversibly when required.

The processes of a high maturity organization should address the following:

• The disposition process covers all records and information in all media. 
• Disposition is assisted by technology and is integrated into all applications, data warehouses, and repositories. 
• Disposition processes are consistently applied and effective. 
• Processes for disposition are regularly evaluated and improved. 
• The organization’s initial goals related to disposition have been met, and it has an established process to ensure its goals for disposition are routinely reviewed and revised.

---

Reference:

1. Information Governance Maturity Model

Why Software Product Delivey is not Identical to a Car Delivery?

I happened to sit in one of the project review meeting where client raised a question on software delivery expecting it to be used in production on the day of delivery by the vendor. He went ahead and started comparing it with a use case of a customer driving off a car upon taking delivery. I know all the project managers out there will jump in to say that don't compare apple with orange. On the one hand, yes, software development is unique and cannot be compared with production of a tangible product. On the other hand, attempts are being made by various standards organizations in helping the industry achieve a high maturity process capability and thus deliver production quality software consistently.

Software product vendors selling or licensing software products can however be compared to Car manufacturers. Take for example, Microsoft Office product suite, one can just go and buy it off the shelf and use it, just like driving off a car. This is possible for product vendors because, the product vendors over a period acquire enormous amount of knowledge on the targeted product domain and in turn subjecting it through as many cycles of testing before announcing its readiness.

A typical car from concept to production may take atleast few years and it would be in the order of around 3 to 6 years. During this period, the product undergoes various cycles of tests, which include crash test, drivability on the road conditions of the target market, etc. Similarly, software product vendors do conceptualize the product idea and then work on it over a period. The vendors are attempting to achieve a faster time to market, but by adopting newer product development methodologies. The one that works best is to identify the smallest piece of the software that can meet certain specific use cases and then build on top of it over a period of time.

In case of a software product, it is the vendor's responsibility to subject the product through various tests in production like environments before getting it out to customers. The tests include alpha and beta tests, where in interested end users are engaged to use it in production environments and collect the feedback on various aspects and the developers working on it to have all those critical issues addressed. Achieving a zero defect state may not be a possibility and vendors take balanced approach as to whether wait until all the identified issues be addressed or reach out to the market with certain known issues, which can be addressed in subsequent product releases.

But it is a different approach when it comes to bespoken software projects. The major challenges with the bespoken software projects that differentiates from software products include:

1. It is the Client who specifies the requirement. Though the vendor might facilitate documenting the requirements, it is the customer who formally agrees as to what need to be produced.
2. Lack of understanding and agreement on the non functional requirements, which are not documented in most cases.
3. The vendor might not be an expert in the target domain area. Though the vendor has expertise in the domain area, it is the customer's need that is final and not the vendor's understanding of the requirement.
4. The ever changing requirements. By the time, the vendor delivers the software, the requirements as agreed by the client would have undergone change due to various reasons.
5. It is difficult to unambiguously understand the requirements as the project progresses through various phases involving humans with varying abilities.
6. There are dependencies with various pre-existing or emerging software and hardware environments in the production environments of the client.
7. The client has the roles and responsibility to assume to make the project successful. However, it is for the vendor to ensure that the client understands their role and responsibility throughout project life cycle.

Another point to consider for this discussion is what constitutes delivery. A well written SoW (Statement of Work) clearly lists down the acceptance criteria, which when met would constitute acceptance of the delivery by the client. For a given requirements, no two vendors would build an identical solution. That's due to the tools, technologies out there for use and the varying intellectual abilities of those involved in building the software. It is important as to what the client wants, than how the vendor delivers the solution. For this reason, the client shall assume the responsibility of performing an user acceptance tests. Some times, the delivery of a software might mean implementation in production environment, which might involve data migration, appropriately configuring various pre-existing software and / or hardware.

In the end, it is all about managing the expectations of the client. It is not just setting at the start, but needs to be appropriately managed throughout the project life cycle.

Characteristics of High Maturity SOA Implementation

Cloud adoption is increasing and so is SOA implementation. As the analysts point out that be it cloud adoption or SOA adoption, unless appropriate governance framework is in place ahead of the adoption journey, it is highly likely that the perceived benefits might not be realized. Benchmarking is a good approach to identify the current state of SOA implementation as compared to an industry recognized maturity model. This also helps to define a target state and then work towards achieving it. Amongst many SOA maturity models the Open Group's OSIMM v2 is quite popular and defines seven levels. While the first three levels are classified as foundational, Level 4 through 7 expects certain demonstrated characteristics and the Level 7 indicates the highest level of maturity.

OSIMM V2 provides the base model which is designed to be extended or customized by the customers and the consulting organizations. OSIMM has seven dimensions across seven maturity levels. The state represented by these levels are given below:

• Level 1: Silo - No integration implementation.
• Level 2: Integrated - Yes, technology is in place to integrate the silos, but they don’t extend to common standards in data or business process.
• Level 3: Componentized - IT systems componentized, but the components are not loosely coupled thus limiting the interoperability
• Level 4: Service - Services are identified and implemented and composite systems are built from the loosely coupled services. However, the composition and the service definition itself are implemented using bespoke code rather than by a declarative flow language, thus limiting agility.
• Level 5: Composite Services - Construction of a business process is possible through use of BPM tools by assembling the relevant interacting services is possible. At this level agility is possible, but developers still have a role to play under the guidance of business analysts.
• Level 6: Virtualized services - At this level the services are virtualized, i.e. a level of indirection is introduced (like a facade layer based on the dependency injection principles), with which the services are more decoupled from the infrastructure on which it is running. But still definition and implementation requires the help of developers.
• Level 7: Dynamically Re-configurable Services - At this level Composite services are assembled in run time by the business analysts or by the system itself, based on various parameters and using service repositories.

Let us now examine Level 7 in detail across the seven domains. Note that like in any other Maturity Model, definition of a level means that the system meets all the previous levels.

Business Dimension:

OSIMM specifies about 19 assessment questions under the business domain and the answers to these questions will be used in assessing the current state. The following are the key characteristics of this domain in practice:

• High Agility - Enterprises services are available on demand.
• Existence of EA - A well defined EA exists, which includes a formal end-to-end definition of business process flow
• Use of BPM - BPM is in use for defining and testing process flows necessary to meet well defined SLAs.
• Integraton - Services being integrated across the enterprise and externally with business partners

Organization & Governance domain:

Under this domain, the focus is on how an organization formally defines and documents their organization and governance processes. OSIMM recommends about 11 questions to gather required information which helps the assessor to form opinion on the current state. When at level 7, the following are key characteristics are expected to be demonstrated:

• Adaptive Enterprise - Ability to adjust operations quickly and smoothly to meet the rapid changes in the market, technology and priorities and being able to evolve with the global economy, so that the services never become obsolete.
• Aligned with Business Strategy - Services are modelled and managed as elements of the evolving business strategy.
• Measurement & Monitoring - Appropriate service metrics are identified, defined and automatically gathered and are effectively used in monitoring and in decision making.
• Governance - SOA governance is part of the organization culture

Method Dimension:

This domain is about the formal use of SOA architectural design, construction and deployment methodology in the organization. OSIMM suggests about 10 questions, with which the assessor will be able to gather required information to map the maturity indicator to the associated maturity attributes. Here the key characteristics that maps to Level 7:

• Adaptive Enterprise - The design, construction and deployment methodologies evolve in line with the industry standards and best practices.
• Dynamic Services - Formal methods exist to leverage architectural constructs and assets for supporting virtualization and dynamic services and BPM.
• Consistent Adoption - Existence of best practice guidance to facilitate consistent adoption of SOA, Virtualization, Middleware technology, Service Registry, etc.

Application Dimension: 

In this domain, the focus is on the Application architecture being designed using the SOA principles, usage of constructs such as loose-coupling, separation of concerns and usage of related technologies such as XML, webservices, service bus, service registry, virtualization etc. The following key characteristics are required to be assessed at Level 7:

• Adaptive Enterprise - In the sense that the enterprise shall be able to adapt to and use the evolving SOA design principles, the tools and technologies.
• Dynamic Application Assembly - The application architecture and design should support the dynamic re-configuration of the services and support consumption of services by external business partners.
• Design Patterns - Extensive use of SOA / ESB design patterns to support BPM.

Architecture Dimension:

The formal use of SOA methods, principles, patterns, frameworks and techniques in the SOA architecture is evaluated under this domain. There are 11 questions to help the assessors to gather required information. The key characteristics of this domain to be an that are required to be assessed at Level 7 are the following:

• Adaptive Enterprise - While the use of formal methods, principles, patterns frameworks and techniques is necessary, these should also evolve in line with the industry practices in architecting SOA services .
• Formal Enterprise BIS - Design and implementation of formal enterprise Business Information Services supporting both the enterprise and external entities.
• Integration - Appropriate architecture is used to support enterprise wide integration and also externally to support partner entities.

Information Dimension:

This domain focuses on the existence of a formal information architecture that supports a master data model and implements a common business data vocabulary. The assessors can make use of 13 questions suggested by OSIMM to assess this domain. The following are the key characteristics required to be assessed at Level 7:

• Adaptive Enterprise - In the sense to have the information architecture evolve in line with the industry standards and practices.
• Vocabularies - Existence of Business data vocabularies, with ability to easily expand or enhance to support new services, business partners and process re-configuration.
• Data definition - Business data is defined using semantic web constructs or ontologies.
• BIS Model - A formal enterprise Business Information Model has been designed and implemented that includes both enterprise and external relationship entities.
• Master Data - Existence and use of Master Data services.

Infrastructure & Management Domain:

This domain is about the IT Infrastructure that supports the non-functional and operational requirements and SLAs needed to operate an SOA environment. There are 12 questions that will be useful for the assessors to gather the required information. The key characteristics that need to be established in this domain are:

• Adaptive Enterprise - In the sense that the infrastructure and related facilities used in supporting the SOA environment should evolve with the industry best.
• Service Management - Tracks and predicts changes to the services necessary to optimize the quality.
• Service re-usability - services are re-used in new and dynamic ways without negatively impactin the Quality of Service.
• Security - Service security policies dynamic and managed in real time.

While the first three Levels are classified as Foundational, the Level 4 is where existence of minimal SOA practices are expected. That way, we can say that one should atleast start at Level 4 and should look forward to transition to higher levels. The Open Group’s OSIMM also lays out the Assessment methods and the assessment questions to facilitate the adoption.

---

References:

OSIMM v 2 Technical Standard.

---

SaaS Maturity Level

Cloud is catching up amongst enterprises. Amidst the security and the other concerns that are still to be addressed, CIOs are seeing a clear benefit in shifting towards the Cloud offerings. That means, there is an increasing number of enterprises seriously engaging cloud based applications. This necessitates the need for a model to measure or assess a SaaS application. Like we have Capability Maturity Model to assess a software development shop to be at a particular level, we need a maturity model to assess the SaaS application.

Microsoft way back in 2006 suggested a 4 level maturity model using Scalability, Multi-Tenancy and Configuration to define various stages. While Level 1 is meant to define an ad-hoc hosted application which lacks all the three basic fundamental characteristics and at Level 4 a SaaS application is expected to meet all these three basic characteristics. This model has its own deficiencies as it does not consider few other important characteristics of a SaaS application, like for instance managing the releases, data isolation, etc.

Forrester has come up with the six level definition of SaaS Maturity. Let us examine each of these levels as below:

Level 0: Just Outsourcing, not SaaS. This is a typical scenario where a service provider operates a software installation for a large customer and cannot leverage this setup for another customer. This is just outsourcing and not SaaS.

Level 1: Manual ASP (Application Service Provider). In this case, the service provider has established unique skill in operating similar service to multiple customers, but each client has a dedicated instance and each instance is manually customized by the service provider to the needs of the customer.

Level 2: Industrial ASP, still not SaaS. The Application Service Provider uses techniques to package and deploy the application with different configurations for different customers. In this case, still the customer does not have the ability to customize their instance of the application.

Level 3: Single-app SaaS. This is when the provider is able to offer application  as service to multiple customers out of single packaged application. This is the initial level of SaaS, wherein the application demonstrates some of the basic characteristics of Software as a Service.  At this level, the provider deploys the packaged application on a scalable infrastructure, and shares the single instance to multiple customers with customization limited to configurations.

Level 4: Business Domain SaaS. At this level, the provider offers a well defined business application and also a host of packaged application modules or third party packages, with which the customer has the ability to extend the business logic of the application.

Level 5: Dynamic Business Apps as a Service. This level is a visionary target where in the provider offers a comprehensive application and integration platform on demand. With this ability, the provider can compose tenant specific and even user specific business applications or services.

SEI has in line with the popular CMMI for development, presented CMMI for services packing in some of the service specific process areas in addition to typical development related practice areas. This however is used to assess an organization offering services as against assessing a SaaS product.

As of now, none of the models are popular amongst the major SaaS vendors, may be because of not enough competition on the SaaS space. Once major players compete on SaaS space, then customers for sure will find a way to assess the service maturity and that could be the way forward.

Please throw in your comments.