Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

The need for Enterprise Self Service Portals

Modern enterprises more and more demand from their IT organizations to take the role of a service provider, provide them services with a minimum of lead-time and on a pay-per-use model. Enterprise business users and even the IT organizations do have a growing desire to be able to request services, in the widest sense of the word, directly in a self-service manner. Modern cloud solutions and especially hybrid cloud solutions provide in potential the answer to this question. 
However, to ensure that enterprises do have a certain form of control and have the ability to orchestrate the delivery of services to end-users in the best way possible while ensuring internal and external service level agreements there is the need for a solid way to provide the services to end-users. And by stating this it is without any question that this needs to be done in a user friendly manner, available on any device and from any location. Just in the same fashion as you would open for example Gmail from Google you should be able to interact with the corporate systems where you can, order, new IT services or adjust IT services.
Deploying services and/or applications can be challenging and complex, traditionally this is done via multi-department change processes where a number of engineers do have to play their part. This process is costly, time consuming, labor intensive and prone to human errors. Automating this process provides a direct benefit to both the IT organization as well as to the business organization.  When automating deployments including all administrative and business processes the need for a solid automation tool becomes clear. 
Within the current market a lot of point solutions are available for a single target platform, when there is a need for a more generic solution the number of options are limited. Especially if you do not want to use a point solution and you do want to provide this in a end-user friendly manner. The “end” in end-user is important in this case. A lot of provided tools are to a certain extend user friendly however define user as a user from the IT department while you do want to provide the portal functionality to real business end-users also. 
Given the above desires and the fact that there are not that many solutions that provide a end-user friendly user interface and the possibility to deploy a wide range of solutions on a wide range of target platforms and clouds it might be desirable for Enterprise to create a custom solution for themselves. 
When developing a custom solution for an enterprise portal one can use the below high level blueprint as a starting point. The below blueprint is based upon a portal developed with Oracle technology and is able to interact with a number of Oracle cloud API’s within Oracle Enterprise Manager as well as other products. 
Enterprise self service portal
The above example uses Weblogic as a platform to run the solution. As can be seen this is divided in two separate sections that both run on a different server. The “front” server is basically used for all human interaction and provides services like administration, reporting, a product catalog and a self-service portal used to request all functions provided via the product catalog. Also approval and communication flows are handled in the “front” server. This is communication to approvers and requesters however also API based communication the “backend” server. The entire functionality is exposed to users primarily via a HTML based interface however it also provides an API option to use the same functionality
The “backend” server is used for communication to all different services living inside and outside of the enterprise. The term services can be used in the widest sense of the word, this can be a IT service however could also be an internal ordering process for office supplies or new business cards. As long as the service is exposed by an API a plugin can be written and included in the “backend” server. You will need to design a standard on how communication between “generic plugin connector” and the plugins is done and when you have established this you can start creating as much plugins as you want. 
A plugin is “activated” as part of the workflow defined in the technical product catalog. The technical product catalog is defining which plugin is called, when it is called and what information it needs to be provided to complete the product. 
As an example, you can define a product where you deploy a new application consisting out of a Oracle database, a Linux application and some users who get access to it based upon a Windows Active Directory. You need to describe the “product” functional product catalog to explain your users what the product is and to define which parameters they need to provide when ordering the product. 
The technical product will be a workflow that will call the “EM12C plugin” that will be used to deploy a new Oracle database on a Database as a Service platform. Next to this the “VMWare plugin” can be called to deploy a new Linux host on a VMware platform, the following step will be calling a specific puppet script with the “puppet plugin” to deploy the application on the new linux host and ensure correct connection to the newly created database. As a last step the users can be “activated” in Microsoft active Directory with the “MS-AD Plugin”. The needed information and conformation is then communicated back to the “front” server and the requesting user is informed.   
There is no direct need for large cloud deployments in your own datacenters, you can use a for example a small cloud internally while doing all your development work and test work in a public cloud. The complexity of making the right decision can be shielded from the customer by making your workflows smart enough to understand how to deploy a solution based upon the lifecycle status of the product. For example, systems with a production lifecycle status will be deployed on your own cloud while systems with a development lifecycle status will be deployed in the public cloud.
Normally this process could take days and multiple administrators and technical staff to create the final solution. However, when you have developed your plugins correctly and have implemented a deployment can be done in a matter of minutes. 
Capgemini has created and operates solutions in line with the above mention for multiple customers and helped them to ensure they become more agile and more cost effective while at the same time ensure that deployed systems are stable and secure. 
For more information about this topic, feel free to contact Johan Louwers directly via

About the author

Johan Louwers

Leave a comment

Your email address will not be published. Required fields are marked *.