This application is related to the application titled, “Business Transformation” filed on the same date by the same inventor.
The invention relates to methods of transforming business operations. More particularly, the business operations are transformed to a portal having service oriented architecture solutions.
Business services providing companies have achieved considerable success in quickly transforming traditional processes using service-oriented architecture (SOA) techniques.
For example, Crawford, et al., in their article, “Toward an on Demand Service-oriented Architecture”, IBM Systems Journal, volume 44, no. 1, 2005, pages 81-107, describe an extension of SOA called on demand SOA. On demand SOA includes comprehensive integration of business process transformation with service-oriented development and policy-based information technology (IT) management.
Cherbakov, et al, in their paper, “Impact of Service Orientation at the Business Level”, IBM Systems Journal, volume 44, no. 5, 2005, pages 653-668, describe the changes needed to transform a company into an on demand business. They describe componentization and the need for service orientation to integrate these components.
Ferguson and Stockton in their paper, “Service-oriented Architecture: Programming Model and Product Architecture”, IBM Systems Journal, volume 44, no. 4, 2005, pages 753-780, describe the IBM SOA programming model.
Rackham in U.S. Patent application 2005/0203784 describes a method of operating a business according to a component business modeling approach.
U.S. patent application Ser. No. 11/496,917 filed Jul. 13, 2006, describes further methods for implementing service-oriented architecture solutions to business models created through component business modeling or other techniques.
The papers listed above by Crawford, Cherbakov, and Ferguson, as well as the Rackham patent application and patent application Ser. No. 11/496,917, shall be incorporated herein by reference in their entireties.
In spite of the developments just described, there remains considerable opportunity for further developments and improvements in the methods of transforming businesses. In particular, the use of portal transformations with service-oriented architecture solutions has been found to have numerous advantages as will be described below. It is thought that such solutions would constitute a significant advancement in the art.
It is therefore a principal object of the present invention to enhance the business transformation art by providing transformation methods with enhanced capabilities.
It is another object to provide methods of planning such a transformation.
It is yet another object to provide business transformation methods which can be implemented in a facile manner.
These and other objects are attained in accordance with one embodiment of the invention wherein there is provided a method of creating a transformation plan, comprising the steps of; creating a portal vision and strategy, creating a security vision and strategy, defining security entry points for a portal implementation with a SOA solution, defining content management strategy, vision, and guidelines, defining and publishing criteria for sunsetting non-value add portfolio components, identifying and defining portal best practices and portlet design guidelines for a SOA implementation, identifying project initiatives underway, timelines, and release plans, creating and publishing a portfolio evaluation report with sunset and migration recommendations, refining the future state architecture, identifying pilot programs and proof-of-concepts, and creating an implementation roadmap.
In accordance with another embodiment of the invention there is provided a method of transforming business operations, comprising the steps of; creating an architecture vision and strategy, defining SOA entry points, creating a portal vision and strategy, defining portal entry points, creating a security vision and strategy, defining security entry points for a portal implementation with a SOA solution, defining content management strategy, vision, and guidelines, creating a business model, identifying domains and prioritizing business functions, creating a system context of current and planned architectural state, defining and publishing criteria for sunsetting non-value add portfolio components, defining and publishing criteria for outsourcing portfolio components, defining and publishing criteria for maintaining portfolio components, identifying and defining portal best practices and portlet design guidelines for a SOA implementation, identifying security best practices and design guidelines for a portal to SOA implementation, identifying governance best practices for a portal and SOA implementation, conducting a portfolio evaluation aligning the portfolio to the business model, identifying and documenting gaps, identifying and reviewing business constraints, capturing new and existing business processes, business services and updating the business model, identifying project initiatives underway, timelines, and release plans, reviewing existing governance best practices, identifying required skills, talent, roles, and publishing a governance best practices document, reviewing project specific budgetary constraints, identifying vendor-specific requirements, creating and publishing a portfolio evaluation report with sunset and migration recommendations, refining the future state architecture, identifying pilot programs and proof-of-concepts, creating an implementation roadmap, and implementing the roadmap.
a-2c are together a flowchart of the steps for practicing the present invention including optional steps.
For a better understanding of the present invention, together with other and further objects, advantages, and capabilities thereof, reference is made to the following disclosure and the appended claims in connection with the above-described drawings.
In
In step 12, a security vision and strategy are created. The security vision and strategy includes authentication and authorization capability for portal access by users. In step 13, security entry points are defined for the portal implementation of the SOA solution.
In step 14, a content management strategy, vision, and guidelines are defined. Steps 11-14 comprise a grouping of steps for strategizing a vision of the transformation solution. Strategizing a vision is the first of three phases needing to be completed to plan for the transformation.
Steps 15-17 comprise a phase of synchronizing the vision by aligning current and planned objectives. In step 15, criteria for sunsetting non-value add portfolio components are defined and published. Published means the criteria are distributed to all affected parties. Components are technical solutions to a business requirement. Portfolio components are those components that are included in the current or planned solution inventory. Sunsetting means use of the application or component will be terminated. In step 16, portal best practices and portlet design guidelines are identified for the SOA implementation. A portal web page may have a plurality of different sets of portlets creating content for different users. By way of example, JSR (Java Specification Request) 168 defines a portlet as a Java-based web component, managed by a portlet container, that processes requests and generates dynamic content. Other specifications for portlets may also be used. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems. In step 17, governance best practices are identified for the SOA implementation. As used herein, “governance” shall be taken to mean the establishment and enforcement of bylaws for designing and implementing a solution. In this case, the solutions are portal solutions in which SOA is the underlying interface pattern. Governance includes the identification of necessary human resources to ensure bylaws are defined, adapted, and executed including execution of exception processes. By way of example and not meant to be limiting, a governing best practice in large information technology departments is to have a portal center of competency in which there is a portal administrator, a portal architect, and an SOA integrator. These three individuals approve all portal related architectural designs before implementation may commence.
Steps 18-22 of
In step 20, a future state architecture is defined. In step 21, pilot programs and proof-of-concept applications are identified. In step 22, an implementation roadmap is created.
In step 31, an architecture vision and strategy are created. The architecture includes an SOA approach to the business transformation using known SOA techniques, such as those described in the documents listed above. In step 32, SOA entry points are defined. In step 34, portal entry points are defined.
In step 37, a business model is created, domains identified, and business functions prioritized.
Regarding the synchronizing phase shown in
In step 44, criteria for maintaining portfolio components is defined and published. In step 46, best security practices and guidelines for a portal SOA implementation are identified. In step 48, a portfolio evaluation is conducted. For each component in the current portfolio, a determination is made whether to include that component in the planned portal solution. If so, any changes needed are determined. If not, then a decision is made whether to sunset the component, or whether certain parts of that component should be kept in the portal solution. In step 49, the portfolio is aligned to the business model created in step 37. Gaps are identified and documented.
In step 50, business constraints are identified and reviewed. By way of example and not limiting, are budgetary constraints, manpower constraints, and location constraints.
c illustrates steps in the realization phase of the business transformation. In step 61, the business model created in step 37 is updated after capturing new and existing business processes and business services. In step 63, required skills, talent, and roles are identified by reviewing the existing client governance best practices. A governance best practice document is published. In step 64, project specific budgetary constraints are reviewed. In step 65, vendor-specific requirements are identified. These requirements came about because an existing solution component may have been provided to the client by a vendor. That vendor may have placed a requirement, such as usage restrictions, on the client. In step 67, the architectural state from step 41 is refined based on information obtained in steps 15 to 19 of
Finally, in step 70, the roadmap created in step 22 is implemented.
While there have been shown and described what are at present considered the preferred embodiments of the invention, it will be obvious to those skilled in the art that various changes and modifications may be made therein without departing from the scope of the invention as defined by the appended claims.