Enterprise Application Integration - Challenges

The increased complexity and diversity in the information systems and the inability to rebuild the information systems from scratch is forcing enterprises to look at EAI as an alternative solution that will help extend the life of the existing applications and also add on newer applications to meet their changing needs. EAI, if not well done could add to the woes of the enterprise. Here are some of the typical challenges an EAI project will face, which need to be worked around to reap the real benefits of EAI.

• Change Management Plan

It is important that the employees are bought in for the EAI initiatives and are taken into confidence for the changes that EAI brings in. With EAI, this is important as the Integration could be between many to many applications not only within the enterprise but also with partner / vendor applications. Many times, changes to such applications and / or the processes are necessary to implement best EAI solutions. Lack of proper Change Management Plan to support EAI initiative would mean resistance or reluctance from various business and IT teams to support the EAI project, which could lead to failure of EAI initiatives.

• Project Costs

According to Gartner 50% of EAI projects are over budget.  Even when cost is under control, the projects slip the schedules and hits production later than expected. Typically, the cost of acquisition of knowledge of various systems, additional software & hardware, infrastructure support, vendor management, etc are ignored or not appropriately estimated in the planning stage resulting in cost overrun. In addition EAI requires lots of technical and business decisions to be taken during the course of the project and that calls for experts with tons of experience who in turn have a hefty price tag. While the project cost itself is not an issue, it is important that the overall cost is well estimated and the return on Investment is well established to the satisfaction of the Management, so that they will continue to support the EAI initiative. If this is not done well and if the project cost keep shooting up every now and then or if the schedule keeps slipping off, then the management is likely to withdraw the support, which would mean shelving the EAI initiatives.

• Continuous Support

Like any other application, the EAI project is not an one-time implementation and it needs continuous support and maintenance. This is evident as the participating applications keep evolving and the business processes around which the integration needs are orchestrated keep changing depending on the growth and diversity of the business operations. In case of most EAI projects executed by vendors, this aspect is ignored and the recurring cost that arise on account of support and maintenance could be a surprise.

• Choice of Technology & Tool

While the business team look for quick and easy solution that is flexible and cheap, the IT team look for reliability and ease of use among other things. The IT team also expects that the business team will be appreciative of certain limitations of the technology and tools, which is an area of concern for the business team. It is extremely difficult to choose a technology or tool that meets all the needs. For instance, especially in the Integration space, EAI tools are great for real time integration of small chunk of data between applications, whereas there are different tools for bulk ETL kind of integration needs. Similarly, EAI tools typically do not support complex transformations and instead the source or target solutions need to be enhanced to handle transformations. The Architects have a key role to play in establishing the process and practice aspects of EAI within the enterprise and it is important that these are thought of ahead of tools and technology selection.

Connecting people and technology is always a challenge, which is magnified further with great many choice of tools and technology. It is important that these challenges are understood well and an appropriate plan to work around these is put in place well in advance would ensure the success of EAI initiatives in an enterprise.

Developers’ take away from a support project

Developers usually tend to prefer development projects over production support projects. Developers always want new challenges in terms of technology and would like to be using the latest tech tools and platforms. As most development projects offer them this advantage, they usually prefer to get away from production support projects.  But in reality, the production support projects do offer them certain key benefits, which are very much required as they move up in their career path. Let us examine some of these here.

The real life business scenarios

A software project begins with perceived business requirements as drafted by the Business Analysts and approved by customers. In most cases, the requirements are far from complete and that leads the developers to live with ambiguity giving room for more defects in the product that they develop. How much ever the software is tested, when it hits the production use, the real life business scenarios will for sure throw the software out of gear and makes it fail. Thus, those involved in the support projects get the opportunity to deal with production business scenarios which will sharpen their business / domain knowledge. Given that the world has started embracing the cloud and SaaS applications, there will be less of development and more of customization and managing the configurations. That means that the need for domain skills with the developers will rank very high amongst the SaaS providers and consumers.

Better product / domain knowledge

In product development, it is quite possible that a developer or a team of developers would be working on just a small part of a product. That means, the developers associated with development projects have very little opportunity to have complete understanding of the product. Whereas the developers involved in the production support would get opportunities to work with all parts of the product and some times across other products too. They get better visibility on the operating processes / practices associated with a use case, there by getting a better product / domain knowledge.

Solution design skill

Developers tend to believe that support projects do not have much opportunity in the solution design space, which is a myth. A production defect is far more difficult to deal with than a defect identified during the development life cycle. Resolution of a production defect involves at a high level the following steps:

• Quickly come up with a data fix to maintain the data integrity if impacted by the defect.
• Perform a root-cause analysis and come up with the real life scenarios that could lead to this defect being encountered.
• Come up with an interim work around if any available to prevent it from recurring in the shorter term.
• Identify a best solution to prevent it from recurring – This is rather challenging as the solution has to be designed within the existing product architecture, with lesser efforts and least impact to the already working software.

Each of the steps when done well in combination with the real life scenarios add tremendous value to the abilities of the developers and that will lead them towards software or solution architects. Solutions in support project see production quicker than the development projects and as such high appreciation from business teams. 

Code Re-factoring

Learning from one’s own mistake is a good way of learning. But, learning from other’s mistake is a smart way of learning. Every time a developer attempts to resolve a production defect, he might be looking into the code written by someone else and may come across many different ways of achieving a result. Taking it positively, a support developer may enjoy reading through the code written by others and pick up some better algorithms and at the same time, how not to write codes. This will for sure better their coding abilities.

The developers in the supporting a production instance of a software product will realize how important the readability of the code is and hopefully they will be making it their habits to write readable code with appropriate comments and indents.

Trouble shooting expertise

Usually software products are moved to production environment after atleast three levels of testing. A defect in production means that it has slipped through all the testing phases during development. So the scenario under which this comes to surface is not something that has been visualized during the development phases. Some of such defects would be very difficult to reproduce without which resolving it would be a nightmare. Those involved in support projects would quite often exposed to such scenarios and they will over a period gain good trouble shooting expertise. Read one of my other blog on Debugging performance problems.

Collaboration with other teams

During development phase, a software developer would be looking up to his lead for any clarifications on the work that is assigned to him and would not get exposed to other teams. Whereas, those involved in production support get to work with various other teams like the infrastructure, IT security, subject matter experts, quality assurance, business analysts, end users, third party vendors when any of their components are used, etc. This collaboration and interaction brings room for acquiring some additional skills both in technical space and also on the soft skill space.

Conclusion

Being in production, support projects facilitates the enterprise to perform its operations and earn profits on an ongoing basis. They play a vital part in the business continuity of the enterprise. As long as a production software is well supported and maintained, the IT heads would not think of replacing it unless a major technology overhaul is expected.

Of course, there are certain downsides of being support projects too. For instance, one may have to be on call to support any emergency and some times, a hard to crack defect could result in tremendous pressure and stress. 

The skills that transform an IT Manager to an IT Architect

One of a typical question that an aspiring architect has to answer in the hiring interview is “how in your opinion an architect is different from an IT Manager?” Even I have been in the asking side, on many occasions and have not been getting convincing answers from many. This is very typical as in most organizations, even if one is titled as Architect, he or she end up managing IT as against Architecting IT. Let us attempt to compare and contrast the skills that these roles demand. Please note this is not an attempt to make out a complete list of skills of these roles.

1.       The Engagement

The Architect’s engagement starts with identification of a business pain point. At times, it would be the Architect who should spot the pain points and propose remedies. On the other hand the IT Manager is engaged the moment a project has been scoped and is ready for execution and implementation.  The engagement of an Architect starts with the challenge of making a business case (of course with the help of fellow architects specializing on specific areas) to the stake holders with appropriate quantified projections that lead to a positive RoI. When this task is done well, the projects that get shelved mid course would come down considerably.

2.       Big Picture thinking

The Architect has to be the one who can visualize the big picture of any given problem or a possible solution in line with the enterprise’s long and short term goals, the anticipated business growth and the technology trends in the related area. This visualization would help the Architects to appropriately prioritize the various initiatives and to draw out the short term and long term road maps. The big picture visualization is an integral part of the IT strategy lifecycle of the enterprise to determine the future state and plan for the transformations from current state to future state. On the other hand, the IT Manager is engaged only in the transformation tasks and there by leading the organization to the future state.

Some of the aspiring architects, when asked how would they do the capacity planning, their response was based on a pinned down Statement of Work, which in case of architect engagement would not exist and they could not think of a situation where they would be designing a solution with absolutely no requirements on hand.

3.       Project Execution

The IT managers will have teams to execute, implement and manage various projects, whereas, the Architect would be playing an independent and in most cases individual contributors. The Architects have to be with the project execution teams and help the teams by bringing in course corrections whenever they deviate from the intended plan. This role requires the Architect to possess hands on ability in the related technology, so as to hand hold the project teams during execution. The IT Managers on the other hand may not be required to do this and instead he would simply co-ordinate the engagement of Architects with the teams.

4.       Risk Management

While Risk management is essential in IT management life cycle, performing it early on adds huge value to the solution execution as it helps better decision making in terms of resource planning, training needs and of course will bring in the ability to remedy the risk. That is the challenge an Architect has to face in identifying all potential risks that the solution may lead to. IT managers also face challenges in risk management, but it will be a lot easier as many things would have gained concrete shape with less ambiguity.

5.       Staying on top of the trends

The IT Managers are not normally pressed to stay on top of the technology trends and it would be enough for them to stay on top of the technology that is mature enough and has good industry adoption. The Architect on the other hand has to stay on top of the trends and that would help him in measuring the longevity of the proposed initiative or solution. It also important for the Architect to have a good grasp of industry predictions and analysis and should have the ability to choose the less risky path to lead the enterprise to the future state.

SaaS Security and Compliance Concerns

Security is one of the major concerns which hold enterprises from embracing the cloud. But some think that this is manageable and as such have started adopting cloud based SaaS applications. Cloud based Enterprise solutions like Sales Force, Service Now, NetSuite are gaining ground. Let us attempt to list down some of the key areas, where the security and compliance needs are different from the on-premise applications.

Data Security 

Unlike on-premise applications, in case of SaaS applications, the underlying data is located outside the organization’s physical / logical boundaries. If the SaaS Provider in turn has hosted the application with a Cloud Platform or Infrastructure provider, then it is true for the Saas Provider too. This very fact that the data is located outside the enterprise could be a serious security concern for some enterprise, depending on the sensitivity of the data and the laws governing them.

Mature SaaS applications do expose Service Interfaces to facilitate data integration with other on-premise applications of the enterprise. Which means these Interfaces also need to be equally secured as these can be exploited to steal or manipulate data.

This means that the data as stored elsewhere should be secured by well established practices and methods like encryption, access control, etc. In addition, all the interfaces that expose data should also be secured using appropriate access control, authorization and logging techniques. The SaaS provider shall also make the data access logs available to the enterprise for review and audit.

Another important area to be concerned about is upon the service termination, how the provider ensures the proper return of the complete data and also make sure the destruction of copies maintained as the services may require.

When the SaaS provider assures adequate back-up and recovery tools and processes, it should also be ensured that the location of the back-up data is physically and logically secure enough and the data is stored with an acceptable form of encryption. Again, access to such locations should also be controlled, so that the SaaS consumers could access only their very own back up data and not that of others.

Data Segregation 

One of the key characteristics of SaaS application is multi tenancy, where an application instance is shared with multiple customers. That means, the customers’ data as handled by the application needs an appropriate physical or logical segregation, so that users of a customer access only their own data. On the consuming enterprise front, this could be a big concern as lack of adequate control could result in data being accessed by other consumers of the application, who could be competitors.

In this context, it is essential to know how the application and data stores are architected and what controls are in place to ensure isolation of customer’s data to its own users only. This is a larger issue and a lapse in one of the following areas could result in a compromise:

• A design or architectural flaw in the user authentication and / or authorization 
• A design or architectural flaw in the customer data separation 
• A defect in the user authentication routine 
• Regression issue caused by a design or application change 

Development Model 

 As we understand, how a flaw or change in the application could compromise the data security, the SaaS provider should also assure the consumers that their application design development model is developed to address the SaaS Security concerns. This means that the SaaS provider should have the following practices as part of their application design and development model.

• The developers should be security aware and the design and code that they produce should be of high standards. The development team should be well trained in remediating security threats as they are detected. 
• The development lifecycle should provide for security reviews and security testing at the end of every phase / sprint 
• As the application instance is shared by multiple customers, there could be need for customer specific patches and far more quicker releases of smaller changes. This may require agile development methods to be adopted. 
• The engineering process should include a configuration management process as the shorter release cycles and customer specific patches would require better source code control and more specifically in code branching and merging. 

Infrastructure Security 

Like in-house production environments, the environments where the SaaS application is hosted should be well secured. The SaaS provider should establish this fact by exposing the process and practices followed for the purpose by adhering to the popular security frameworks and standards. This need is the same as like in case of on-premise or cloud hosted enterprise’s own applications.

Regulatory Compliance 

There are a number of legislations in various countries, which stipulates for compliance to certain processes and practices when it comes to data. For instance in US we have HIPAA, SOX, etc. The SaaS model complicates this further as the enterprise may be operating out of a location in a country and the SaaS provider may be operating out of a different country and the data could be located in yet another country or even countries.

Again, in the SaaS provider perspective, customers from all over the world may subscribe for the application and in which case, the provider should establish necessary compliance practice to meet all such legal requirements. Some countries have legal requirements to retain data for certain minimum period, which the SaaS vendor should support.

It is needless to say that the governments would be monitoring the cross border data traffic and would seek clarifications and explanations and for which adequate audit trails and logs are essential.

Identity Management 

Provisioning users and managing their access and authorization permissions for various applications is becoming increasingly complex and enterprises are looking at central identity stores coupled with single sign on to address this problem. With SaaS, this could bring in additional complexity. Most enterprise SaaS application providers offer support for local store and as well as integration with enterprise’s very own identity store.

In case of local identity store, adequate security around the identity store and the process around managing the identity store gains significance. Any lapse in this area could lead to data a compromise in data security.

In cases where integration with enterprise’s own identity store is preferred, then the additional concerns could be in the areas of establishing trust relationships with the SaaS application and securing the federation of user identities between the identity store and the cloud hosted SaaS application.

Conclusion 

Adopting a SaaS application does not absolve the enterprise from governing the information assets associated with such application. The CxOs of the enterprises will still be responsible whether these are managed on-premise or by the SaaS vendor. The SaaS vendors in turn should make sure that they comply with all these needs so as to win the confidence and trust of the enterprise for selling the software services.

Check out my presentation on the same topic on slideshare.

Driving fast into the Tech Lane

As I was driving down to a restaurant with a friend of mine, we were chatting about another common friend and his new venture on mobile applications. The conversation soon gained technical flavor and it was a nice drive into the fast changing technology lane. Here are some excerpts from our conversation during the drive.

On why enterprises are in a hurry to port existing applications to mobile platform...

The technology is evolving so fast and enterprises will soon be embracing mobile devices which range from smart phones to tablets. Every tech worker owns a mobile smart device of his or her choice. Most such workers are holding senior positions in the enterprise and are very keen to use it to perform their work and for the purpose, try to influence the IT heads to allow such devices in work environment. This in fact is a challenge for the CIOs in terms of information security and confidentiality. But as this trend is growing, the IT heads have no option than to embrace this trend and start regulating this with a formal BYOD (Bring Your Own Device) policy, controls and governance framework around it.

On how BYOD is relevant in the context of mobile applications...

Yes, as the BYOD is gaining increased acceptance, the next big challenge is to get existing applications working on such devices, so that the employees don’t have to be provided with a desktop or even laptop. This in turn drives the need for porting the applications to mobile platform. Many tools and methodologies are emerging in this space so as to facilitate building mobile applications from ground up and also to port existing legacy applications to mobile platform. Write once deploy any where is the USP for today’s development tool vendors.

On how legacy applications can be ported...

This is where the Service Orientation is gaining importance. Business services are identified and exposed as reusable services and then build a portal application on top of it to appropriately present it for end user access on a variety of devices. The organizations would also consider embracing the cloud based SaaS applications to replace the legacy applications. And yes, migration to cloud could be a daunting task but CIOs are seeing a longer term benefit in doing so. An alternative shorter term solution could be to get a virtual desktop on the mobile device and then work on whatever legacy app that runs on the desktop.

About the concerns on cloud...

Yes, there still are certain concerns that keep organizations away from the cloud. However this trend is changing. Most organizations have already moved less critical applications to the public cloud. Like we have central / reserve banks regulating the banking industry, it is time for the industry consortium to come up with an independent regulatory body / framework, which can help establish the trust amongst the enterprises, which in turn will ease some of the security concerns. While industries like Banks and healthcare providers have reasons to be concerned to embrace cloud, other industries are showing serious signs of embracing the cloud.

On the amount of data that banks process and manage and whether that could be a deterrent for cloud adoption...

Be it cloud or not, data quality and data maintenance is going to emerge as a critical function. Dirty data and redundant data is being identified as having considerable impact on the profits of the organization. Tools have emerged in assuring data quality, data de-duplication and master data management. Computing hardware and related technologies like virtualization has made vertical and horizontal scaling very easy and thereby making the usage of these data intensive tools a possibility.

We both enjoyed this conversation and I am sure, you would also enjoy reading this. 

Debugging a performance problem

As with any typical Application development, performance is mostly conveniently ignored in all the phases of the development life cycle. In spite of it being a key non functional requirement it mostly remains undocumented. It is more so, as the development, test and UAT environments may not really represent the real world production usage of the application as some of the performance problems could not be spotted earlier. Even if the application is put to load test, there are certain in the production environment, like data growth, user load, etc, which may lead to performance degradation over a period of time.

While most performance problems could easily be spotted and resolved, some could be a challenge and may require sleepless nights to resolve. A structured approach may help addressing such issues within reasonably quicker time frame. Here is a step by step approach which should work in most cases.

1.       Understand the production environment

It is important to understand the production environment thoroughly so as to identify the various hardware & networking resources and the middleware components involved in the application delivery. In a typical n-tiered application, it is possible that there could be multiple appliances and servers through which a requested passes through and get processed before responding back to the user with response. Also understand which of these components are capable of collecting logs / metrics or capable of being monitored in real time.

2.       Understand the specific feedback from the end users

Gather details like who noticed the performance degradation, at what time frame, whether it is repeating at pattern or just pulling the system down. Also understand if the entire application is slowing down or some specific application components are not performing. Also try to experience the problem first hand, sitting alongside an end user or if possible use an appropriate user credentials to experience the performance issue. The ‘who’ also matters as in certain circumstances, the application slow down may be for a user associated with some specific role as the amount of data to be processed and transmitted may differ based on the user role.

3.       Review available logs and metrics

Gather available logs and metrics data collected by various hardware and software components and look for information that could be relevant to the specific application, or more specifically the set of requests that could demonstrate the performance issue. As Logging itself could be performance overkill, it would be ideal to switch off the logs or to set it to collect only minimal logs. If that be the case, configure or effect necessary code change to achieve appropriate level of logging and then try to collect the required details by re-deploying the application on to a production equivalent environment.

4.       Isolate the problem area

This step is very important and could be very challenging too. Take the help of developers and performance and load testing tools, to simulate the problem and in the meanwhile monitor for key measurement data as the request and response pass through various hardware and software components.

By analyzing the data gathered from the application end user or out of the first hand experience, and with the available logs and metrics try to isolate the issue to a specific hardware or software component. This is best done by doing the following step by step:

a.       Trace the request from the UI to the final destination, which typically may be the Database.

b.      If the request could reach the final destination, then measure the time taken for the request to cross various physical and logical layers and look for any information that could cause the slow down. If a hardware resource is over utilized, it could so happen that the requests would be queued up or rejected after a time out. Look for such information in the logs.

c.       Then review the response cycle and try to spot the delays in the return path.

d.      Try the elimination technique whereby, the involved component one after the other from the bottom is cleared of performance bottleneck.

Experience and expertise on the application and the infrastructure architecture could come in handy to spot the problem area quickly. It is possible that there could be multiple problems whether contributing to the problem on hand or not. This situation may lead to shift in focus on different areas resulting in longer time to resolve the problem. It is important to always stay in focus and proceeding in the right direction.

5.       Simulate the problem in Test /UAT environment

Make sure that the findings are correct by simulating the problem multiple times. This will reveal much more data and help characterize the problem better.

6.       Perform reviews

If the problem area has already been isolated in any of the steps above, then narrow the scope of the review to the components involved in the isolated problem area. If not, then the scope of review is little wider and look for problem areas in every component involved in the request response cycle. Code reviews to debug performance issues require unique skills. For instance, looping blocks, disk usage, processor intensive operations could be the candidates for a detailed review. Similarly, in case of distributed application, look for too many back and forth calls to different physical tiers could easily contribute to performance problem. Good knowledge on the various third party components and Operating System APIs consumed in the application may sometimes be helpful.

When the problem is isolated to a server and the application components seem to have no issues, then it might be possible that any other services or components running on the server might cause load on the server resources there by impacting the application being reviewed. If the problem is isolated to Database server, then look for dead locks, appropriate indexes etc. Sometimes, lack of archival / data retention policies could result in the database tables growing in a much faster pace leading to performance degradation.

7.       Identify the root cause

By now one should have identified the specific application procedure or function that could be the cause of the problem on hand. Have it validated by doing more simulations and tests in environments equivalent to production.

8.       Come up with solution

It is just not over yet, as root cause identification should be followed by a solution. Sometimes, the solution to the problem may require change in the architecture and might have a larger impact on the entire application. An ideal solution should prevent the problem from recurring and at the same time it should not introduce newer problems and should require minimal efforts. Alternatively if the ideal solution is not a possibility with various constraints, a break-fix solution should be offered so that the business continues and also plan for having the ideal solution implemented in the longer term.

Hope this one is useful read for those of you in production support. Feel free to share your thoughts on this subject in the form of comments.

Governing Identity Management

Traditionally, each software application is developed to maintain and manage the identity and the related permission information within it. As more and more such applications gets deployed, user provisioning and managing access control could soon be a nightmare. A well managed Identity Management function within an enterprise can alleviate the hassles around this and will also enable the enterprise to better govern the identity and resource provisioning activities.

Identity Management solution as such comprises of the following key functions in addition to being technically capable of exposing necessary automation APIs:

Account Provisioning

This is a core function within Identity Management and this is where an identity gets created.  The following are the typical activities that need to be performed under this function.

• Adding an Identity - includes receiving a request with required data, performing necessary verification and obtaining approval from appropriate authority.
• Modifying an Identity - involves change of certain attributes of an identity.
• Deleting an Identity - when an identity no is no longer associated with the organization, deletion may be required. Deletion may not mean actual deletion and instead may mean de-activation.
• Suspending / Resuming an Identity - usually when employees go on long vacation, it would be appropriate to suspend the identity and resume again when the employee comes on board.

Resource Provisioning

An Identity once created need to be provisioned to access one or more services, which could be out of a computing resource or a non computing service. For instance, computing resources could mean access to payroll application and similarly a non computing resource could mean physical access to the Data Center.

De-Provisioning

De-provisioning is an equally important function which, if not done on a timely manner could put the organization into a big risk. For instance, if an employee who has been granted access to critical systems, is not de-provisioned when he leaves the organization, he could cause potential loss to the company.

Managing Permissions and Authorization

Provisioning a resource would only mean that the resource has a need to use the target resource, but it has to be further managed by defining specific privileges like, Read, Write, Delete. Similarly, the identity may have to be granted different permissions for different sub functions that the resource may expose. While a standards based IAM solution would be extensible, the consuming application may require changes to interact with the IAM solution and make use of the authorization information that is exposed.

Governance

With a central identity management solution, it is important that the related functions are better managed, monitored and audited. This requires defining, implementing and monitoring controls around people, process and tools & technology.

• People – The person performing the one or more of the above functions should be highly trust worthy and appropriate separation of duties and responsibilities should be put in place. For instance, the person approving the identity creation should not be the same person who creates it. The identity performing these functions should be at appropriate level which ensures accountability. 
• Process – Policies and processes need to be defined for each of the above functions. For instance, Identity creation shall specify the source of data, the required attributes for which data need to be captured, a process or methodology to have the identity information verified and on top an approval process. It is typical that the approving authority may be different for different resource, which has to be unambiguously defined. There should also be a process specifying the monitoring and audit requirements for the above functions.
• Tools  & Technology – Carrying out the above functions will certainly need an appropriate tool and related technology. A comprehensive enterprise tool may facilitate carrying out all the required functions in addition to offering necessary APIs for the resources that consumes the authentication services. It is important to specify how access to these tools and related infrastructure is protected and governed.

The following are the key control objectives that need to be defined with respect to each activity performed under Identity Management:

• Identification – the security control process that creates an entity and verifies the credentials of the individual, which together form a unique identity for authentication and authorization purposes
• Authentication – a security control process that verifies credentials to support an interaction, transaction, message, or transmission
• Authorization – a security control process that grants permissions by verifying the authenticity of an individual’s identity and permissions to access specific categories of information or functions exposed by a resource.
• Accountability – a security control process that records the linkage between an action and the identity of the individual or role who has invoked the action, thus providing an evidence trail for audit or non-repudiation purposes
• Audit – a security control process that examines data records, actions taken, changes made, and identities/roles invoking actions which together provide a reconstruction of events for evidence purposes

All the control objectives above serve the requirement to provide an auditable chain of evidence.

Identity management control processes should have an input, one or more control activities, an output, feedback, management monitoring, and an overall audit appraisal activity to ensure that they are fit-for-purpose. The starting point is an individual who is enrolled into an organization and subsequently acts in a function or role in the organization. The individual may be an employee, partner, or contractor, or third party. The output is the appropriate degree of policy enforcement and individual accountability for the business activity. Within the controls, the threats and vulnerabilities constituting the business risk must be addressed and assessed. These include business, legal, and technical aspects.

Like with any systems, the following are the key non-functional requirements an Identity Management infrastructure should aim to offer.

• Being more responsive and secure
• Interoperability with a multitude of systems requiring identity information.
• Support for multiple authentication mechanisms, like two factor, bio-metric, etc.
• Interfaces and APIs for automation which could result in reduction in operational costs.

A governance framework would not be complete if it does not define the measurements that indicate the efficiency and effectiveness. The following are some of the metrics that could be considered:

• Password Reset volume – A well managed Identity Management System is expected to considerably reduce the help desk calls on forgotten passwords. As such a measure of this activity could be a key metric to establish that there is a considerable saving in such help desk activities.
• Number of distinct credentials per user – With Single Sign On implemented, there should be only one distinct credential per user.
• Average time taken for each of the identity management functions could be another useful metric to establish that the investment is worth.

References:

White paper on Identity and Access Management published byThe Open Group

More related reading:

Liberty Alliance Project 

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.

Code Review – How to get it right?

Code quality is one of the often talked about issue in a project status meeting. The magnitude of this issue will be bigger in case of maintenance products, where end users are encountering defects. While all the members of the project team very well know that code review if done well during the build phase could reduce the code quality issues by a significant percentage. The design and build process manual clearly calls it out that code review is an exit criteria for the code to move on to QA for testing. But still this issue surfaces every now and then.  

The question that comes up is whether code review was done at all or done just for the sake of process compliance. The possible reasons for reluctance among the developers to do a peer review are: Lack of reviewing skills, using the review finding against the developer for reviewer's personal advantage, inferiority complex of the developer. The other most common reason cited attributed by developers is lack of time. 

As all of us are very clear on the benefits that the code review bring on the table, let us not try to list out and discuss about the benefits. Let us attempt to list down the required skills of a code reviewer.

Subject matter (Domain) expertise:  Though most developers are not expected to be domain experts, this skill will certainly be required if the code review is expected to prevent functional defects getting slipped into the next phase. The very fact that the developers need not have domain expertise could possibly mean that the developer might have not understood the requirement as it was intended to be resulting in injection of defects. A mis-interpretation of the requirements could result in a functional defect and there is a chance to spot it if the reviewer posses the domain expertise. Some of the production defects could be unique and may not be reproducible and in such case, code review is the recourse to trouble shoot. This if done well during the build phase, could have prevented such defects surfacing in production at a later stage.

Technical Skills: The reviewer should be an expert in the technology and the programming language used. In software programming, code could be written in innumerable ways for a given requirement. However, given the standards and practices the team is expected to follow, the various quality attributes identified for the project and the goals set for the specific review, the reviewer should possess appropriate level of knowledge to spot problem areas. It is important for the reviewer to know the internal subsystems and the inter dependencies on various local and external computing resources.

Positive Attitude: This is a very important skill for the reviewer and the reviewer should never use the review findings against the developer as an individual. The issues should be considered as a team issue. The Reviewer should acknowledge the capabilities of the developer and the developer may have valid reasons for having written code in a particular way. At the end of the review, it would be a good idea to discuss the summary of the findings with the entire team, as some findings could be good learning for other team members. The organizational standards and practices should also be revisited and revised if necessary based on the nature of the findings. This may also result in identification of certain training needs for the team.

Team Skills: Both developer and the reviewer should have the common objective of producing quality code out of the build phase and they must work as a team to achieve best results. If not, the code review may happen just for name sake or may lead to personality issues which in turn would affect the project deliverable.

Attention to Details: This is an important skill a reviewer should possess to carry out effective reviews. Typically it is human to miss certain blocks of code as parts of it may appear to be correct. Unit testing is not a substitute for code review. The reviewer should with respect to each line of code, ask questions like, what if this statement fails to execute, if there is any other best way to achieve the same action, whether this could lead to potential performance issue, whether this statement may require more system resources, like Memory, CPU time, etc.

Knowledge on Tools: In addition to the above, code reviews with certain specific goals will require knowledge and expertise on appropriate debugging and diagnostic tools.

One of the key metrics in the Software Engineering space is defect injection ratio. This helps to identify the phase that has injected most number of defects. Many times, the stake holders think that it is the developers who inject defects into the delivered software. The reality however may not be completely true as much number of defects get injected in the requirements and design phase also. However, code review when rightly used, helps the development team not only to keep the defect injected in the build phase under control, but also not let the requirements / design phase defects slip into the next phase. 

Solution Architect - Understanding the role

I keep getting questions from some of my friends, as to what the role Solution Architecture is all about and will they be a fit for that role. For the benefit of every one out there, I thought of putting together my thoughts on the role of Solution Architect. Let us first examine what is expected out of this role and then look at the skills needed to be in this role.

As the title indicates very well, the role is expected to bring in solution to varying business problems, most which could be a product or project by itself. But, as you know, it is always a challenge to come up with a best solution due to it being intangible and that there are many quality attributes which are not completely identified and specified. There would be lots of missing links in the areas of business domain, choice of technology, hardware components, business processes, future domain and technology trends, etc  which the Solution Architect should be able to connect and come up with best solution that could last longer, so that the organization reaps the return on investing in the solution.

Some of the key characteristics of a best Software Solution are:

Longivity: While the solution must solve the current business problem, it should also be reliable, usable, secure and also future proof. This means that the solution Architect should consider the industry and technology trends that could have an impact on the problem / solution in the near and longer term.

Trade off: The challenge with the various mostly unspecified quality attributes is that they are interdependent. And meeting one such attributes may most likely mean compromising on another. Obviously, a lot of trade off has to happen between various quality attributes and such trade off should be justifiable in the context of perceived benefits for the organization. For instance, performance may have to be compromised to achieve better security. The tradeoffs have to be carefully made after considering various factors, like the risk appetite of the organization, target users of the solution, the technology platform, current IT investments of the organization, etc.

Implementation view: It is important that the solution should be devised with the intended deployment view into consideration. Without that, it could so happen that the solution as designed and built may call for massive changes to the infrastructure investments, which could be a total surprise for stakeholders. Such surprises emerging towards the close line of the project could increase the cost by manifolds or delay the project further.

The above is not the exhaustive list. There are many other factors that will have to be given due consideration before coming up with the best solution. Above all, the solution architect should be able to see that the solution is successfully implemented and put into use. That means, a lot of work in terms of convincing the stakeholders as to why this solution and not an alternative, hand-holding the design and development team and also to some extent the end users to have it implemented the same way it was intended.

With all the above, let us now try to identify the essential skills of an aspiring Solution Architect:

Domain skills: A thorough understanding of the business domain is required to first understand the problem better and second to know the potential future needs that may emerge along the same lines of the problem space. It is also important that the person has the ability to learn things fast, as in most cases, there won’t be lead time for him to gain appropriate business skills. That means, the Solution Architect should also be a Business Analyst.

Technical skills: A thorough understanding on the technology currently in use in the organization, the technology currently in use in similar industry domain and the emerging future technology trends. This knowledge is essential to ensure that the solution does not become obsolete soon and that the organization is in a position to be ahead of completion in terms of IT enabled capabilities. At the same time, applying a new technology early in its evolution has its own issues and it is always better to wait for the technology to evolve and mature as more and more organizations adopt the same. It is important for a Solution Architect to closely follow technology trends and gather enough knowledge to understand what could be the best fit for solving various business problems on hand. He should have enough understanding of the technology chosen, so that his team (mostly himself) comes up with a prototype to establish that the solution really solves the problem. However, as the solution goes further down the implementation lane, the Solution Architect should be able to demonstrate hands on skills, so that he could command expertise and be the go to person for resolution of issues.

Team skills: Though mostly the Solution Architect will be an individual performer, some organizations may have dedicated teams to assist the Architects. Even in case of Architects acting as individual performers, the solution is implemented by a project team. So, the Solution Architect needs to be a team player and should with his domain and technical expertise, lead the team by example.

Process / Project Management Skills: Needless to say that the Solution Architects have to have the Project Management skills too, as one may have to manage the pre-solution activities as a project. For the purpose, he has to be familiar with the processes as well.

That means, the Solution Architect should be an all rounder with moderate to expert level skills in all the areas.  On top of these skills, one has to understand that solutioning is not just a science, but also an art, which is mastered with years of experience over as many projects and years involving various technologies and domains.

There could be different views on this and comments or opinions are welcome.