Here is a link to find out if it does : Take the quiz!!!http://bizsensors.com/quiz.html

soumadeep Email Entry

Its a well accepted fact that spreadsheet is a tool which analysts, business executives and the rest of the crowd swear by. But did you ever realize that the data that’s in there is being manually fed.Here many things can go wrong 1) wrong data 2) uncensored data (no access control) 3) stale data 4) data of convenience!Strategist, specially at the top would be taking decisions based on information from spreadsheets which can either be or all of the above mentioned points.One may argue that their data is correct and up-to-date but in reality information gets biased as it travels up the hierarchy. And here we have key people in an organization taking important decisions based on them.Operational BI on the other could provide a framework which will directly feed data into the system from various sources and be able to present information which is unbiased and would not only help take better decisions but take informed decisions in near real time.I believe that Business Intelligence is critical in the decision making process but without a proper data  source mechanism in place it could lead to results best avoided.

soumadeep Email Entry BI of convenience, Operational BI, spreadsheet, spreadsheet and bi, Spreadsheet BI

There has been a lot noise around traditional BI being a failed promise. In fact, Market Dynamics, a UK-based research organization, published a report on how Fortune 500 companies are losing millions of dollars in lost opportunities.Can it truly be attributed to traditional BI alone? Well, to answer that question one needs to comprehend the context in which BI is implemented.Traditionally, IS reports have been used by management executives to formulate strategies for their organization at a global level. Say, for instance, a pharmaceutical company would be more interested in identifying patterns to better understanding the usage of a particular drug for a region or occurrences of particular diseases in a geographic location.These, as you may well understand, are data which have been accumulated over a period of time, at times ranging in years. On the contrary, a downstream manufacturing company would benefit more from tracking whether their shipments are being delivered on time as that affects their business directly.As you can see, that the former approach falls more in the traditional BI category where the top brass would use the data to start an R&D initiative for a new drug or come up with a strategy to position a different drug for a particular market. The key thing to note is that to take such a decision you would require data with a wider time window, possibly a few months/years of data.In the latter scenario, the time window to respond to anomalies is extremely short and it directly impacts operations within as well as outside the organization to make decisions very quickly. As an example, a semiconductor company could be providing low budget components to mobile manufacturers. In today’s uncertain times, most of the manufacturers keep a very low inventory and are dependent on the downstream suppliers to deliver components in a timely manner as their assembly line is completely dependent on it.As you may be aware that a delay in shipment can trigger a flurry of activities affecting the line of business executives directly dealing with the customer, the finance department as a delay in shipment could affect the payment position, the planning department would need to rework on the next schedule and above all the customer would have to be informed about the delay so that they could possibly take necessary actions to handle their assembly line. This is what operational BI would help in solving: a short time window and people at the operations taking immediate decisions.Having said that, traditional BI is important, especially when identifying patterns to formulate strategies. On the other hand, for organizations to operate to the strategies, operational BI is better equipped to address it.In a nutshell:
Operational BI

• Alerting on predefined Key Performance Indicators based on thresholds
• Shorter time window, more operational visibility
• Quick response time
• Information available to the right people at the right time
• Transactional

Traditional BI

• Helps in identifying patterns
• Works on a wider time-window
• More towards formulating strategies
• Deals mainly with historic data

Key areas for success — in general:

• Quality of Data
• Indentifying organizational-specific KPIs
• Aggregation of data from various sources
• Data source format and integration

As you can see, for the latter scenario an approach based on traditional BI may not suffice as the time to react is very short whereas for the former scenario operational BI would not be effective as given the short time window, a strategist may not be able to conclude based on the data points available.

soumadeep Email Entry Operational BI, Traditional BI

Problem:A BPO organization was having difficulty in identifying the root causes of their poor performance from a profitability perspective. The key concerns were not with customer satisfaction or quality of service. Every quarter they were losing millions despite the high customer satisfaction and with a distributed network of centers across different states the problem got even compounded.

Solution:The company hired a consulting firm to provide a solution to this problem as they could go out of business in another 6 months. The consulting firm identified some key KPIs at a high level which are most significant to any BPO organization: Quality Average Handle Time Customer SatisfactionTo monitor these they needed a tool which could provide them with real-time data which would then help them identify the problem areas. In this case they suggested an Operational BI tool as they wanted a Platform by which they could define the required KPIs (coarse grained as well as fine grained), to evaluate KPIs- they required real-time data and to trigger them based on thresholds, a workflow based tool to orchestrate processes and analyze them and above all have a consolidated dashboard which could give them the right information at the right time.The selection of a proper tool was critical as on an ongoing basis it would provide key insight to the organization even after they (consultants) left.

Gourangi – Operational BIAfter evaluating products in the operational BI space the consultants selected Gourangi as it offered the right set of features to track and resolve operational problems including a BPM suiteIdentifying the problem and resolutionVarious data points were tapped to define the three critical KPIs – Quality, AHT and Customer satisfaction using aggregated values across different centers. To monitor them they provided appropriate thresholds to each of the KPIs along with a Dashboard. They also defined a Workflow to handle anomalies in case the value exceeded the threshold.For a few weeks they monitored the KPIs and found out that the supervisors as well as the managers from most of the centers gave a lot of importance to customer satisfaction. These were more pronounced from the workflow analytics as for each AHT alert (high value) no corrective measures were taken to lower AHT and also the wait time for each task was considerably high.On the other hand customer satisfaction was high as the operators were spending more time with the customers but again quality of Service was low as rather than answering to the point and signing off quickly they entertained questions that were unrelated to the actual reason for the call. This also highlighted the fact that either the operators were not properly trained or they were not equipped to handle customers.The major cause though was still due to a High AHT value as the teams across the states were unable to handle higher volumes of calls on a per day basis. This led to an overall efficiency of 50% - attributing to overall losses.

Key Takeaways:The BPO organization re-aligned their operational and execution policies to keep a balance between the three key KPIs across their centers. Gourangi was implemented across various departments to keep a track of the ongoing activities and also to create a collaborative environment where key individuals from various hierarchies could take decisions by using information - at the right time and maintain the much needed balance between Customer Satisfaction, AHT and Quality.

soumadeep Email Entry BPO, BPO Case study, OBI, Operational BI

Come and participate in the 3 day workshop on how you could benefit from MDM, Operational BI and SOA. Our key consultants will help you unlock the complex web of data flowing across your organization and help you expose them as meaningful information which the decisions makers can use to take informed decision in real time.

Event:MASTER DATA MANAGEMENT for SUCCESSFUL OPERATIONAL BUSINESS INTELLIGENCE - 

 8th - 10th February 2010 Holiday Villa Subang, Selangor MALAYSIA Click here for more… 

Soumadeep Email Entry Finance and technology, Malaysia, MDM, MDM event, Operational BI, Operational BI event, SOA, SOA event

For many enterprises, strategic BI has played a key role in the overall decision making process. Where trends and patterns for various business entities were identified and company wide strategies were drawn. But lately, the enterprises are realizing that its NOT enough as Strategic BI heavily depends on data marts or a data warehouse, the reason being the latency. By the time data is put in the warehouse and information is extracted, critical time is lost leading to lost opportunities from the operational point of view. Say for instance, if there is a delay in delivery then its important to notify the Production unit, Finance, Line of business Representative as well as the customer. This has various advantages and most importantly the customer will appreciate it even more as they could reschedule their production plan and save a lot of time and money, it also helps maintain the relationship with the customer to curb customer attrition and also allow the internal folks to re-schedule or re-prioritize delivery.

This is where Operational BI helps enterprises to leverage the transactional data available, process it and alert respective entities within as well as outside the organization. It also by-passes the data warehouse route and minimizes the information turn-around time.

For more on Operational BI - read the feature Operational BI vs. Traditional BI - http://www.ebizq.net/topics/bi/features/11716.html

Soumadeep Email Entry Operational BI

In most of the cases we see that SOA initiatives are driven by enterprise architects. The reason they are funded in the first place could be because SOA promises reduction in overall IT costs! From the tools that are available today we have Service Registries, Web Services Management,BPEL, ESBs and Governance based products to name a few. No doubt that they play a key role towards enabling SOA but do the business users really benefit from these tools? Say from a “Line of Business representative’s” perspective one could possibly use the Service specific information provided by the WSM tools such as Service Faults, SLA breaches for the service, Transactions Per Second…But they are all very service specific! what happens to the data that is passing through it? The data which is all important and is instrumental in running the enterprise itself!!! Do we see a convergence here where the concepts of Business Activity Monitoring and Web Services Management could be merged to benefit the Business Users and attribute to the overall profitability?

Soumadeep Gourangi

SOA Roles
Keeping with the Design Time, CHange time and Runtime paradigm in the SOA Governance space, new roles have come into existence as enterprises gain more insight by SOA implementation experiences:
Role category
In order to comprehend the life cycle of a service and the usage the following categories were taken into consideration.
Provider
An organization that provides/develops native services to be consumed by other actors.

Consumer
The organization that would consume the native service provided by the Provider Organization
Intermediary
A Proxy or Agent based application that would broker messages between the Provider and Consumer organizations enforce policies, provision users, gather statistics

Specific roles for the categories
Provider
The roles played during the life cycle of a service, from a provider’s perspective would mainly be:
System Administrator: This role will have all the privileges available and in addition will be able to assign various roles and privileges to other users of the system, in short provision users. They will also be responsible for maintaining security related artifacts such as Certificates, CRL locations.
Business Service Analyst or Business Analyst: In this role the user will ensure that the business requirements are met by different services that would be offered and would help others understand the business value of the service.
Line of Business Representative: These users will communicate business requirements and identify business services. Will also be responsible for providing Consumers to access services and define consumer specific terms such as security, SLA and other policies which need to be enforced. Could also create composite applications using existing services Note: this role will surface mostly in a brokered proxy mode.
Service Administrator – The users of this role will be solely responsible for a service or a group of services, will track usage and monitor them for the purpose of ROI and also track and maintain the life cycle of a Service such as versioning, deprecation, EOL. Apart from this will also be responsible for managing all other artifacts associated with the Service such as Dependency Profile, impact analysis.
Service designers/Developer – The users of this role will focus mainly on the development of the Services and would interact with the Business Analyst and the Service Owners.
Service Testers – In this role a user will test and maintain the services in terms of the business requirements as well as policy compliance.
Service Monitoring Representatives: In this role users will monitor all services and help in resolving all SLA related activities.
Note: Any other user apart from this will be treated as a guest user. (Please check the Consumer section for more details on the guest user’s access privileges)
Consumer
The roles played by the consumer are limited to service subscription, usage and view statistics.
1) Service User: A service user will be able to use a service or a group of services and will not be able to view statistical data associated with the services in terms of response time, faults, number of hits, service usage, and service usage by user for a particular consumer organization.
2) Power User: These users will be more from the top management of an organization and apart from being able to use a service will be able to access statistical data, view the availability of new services provided by the provider organization and subscribe for them.
3) Service Monitoring Rep: These users will just monitor the statistics of the services that are being consumed. In case of breach of contract will initiate a dialog with the provider organization.
4) Guest: A guest users would be required so that people without any credential can come and view available services. They would not be able to use any service but can request for a subscription. The provider organization should be able to receive this request and process it. The life cycle of such request would be
a. Depending on the service the service provider will be notified with users details which the guest user needs to provide while requesting for a subscription, typically the details would be i) User Name ii) Organization name iii) address iv) email v) phone vi) fax.
b. Once the request is received by the provider organization the processing will start. The subscription work flow could be made part of our application or could be done offline.
5) Anonymous User: When a proxy service is used by user without any credentials the request shall be treated as an anonymous access and if for the service anonymous access is allowed then a proper response will be sent back to the requester or else a SOAP fault can be generated which will detail the cause of failure.

Intermediary
The Roles for this category will be in line with the provider organization and behave exactly like the provider roles but with some added responsibilities.
System Administrator: This role will have all the privileges available and in addition will be able to assign various roles and privileges to other users of the system, in short provision users such as Consumers and internal users. They will also be responsible for maintaining security related artifacts such as Certificates, CRL locations.
Service owners – The users of this role will be solely responsible for a proxy service or a group of proxy services, will track usage and monitor them for the purpose of ROI and also track and maintain the life cycle of a Service such as versioning, deprecation, EOL. Apart from this will also be responsible for managing all other artifacts associated with the proxy Service such as WSDL and impact analysis.
Runtime Policy designers/Developer – The users of this role will focus mainly on creating policies for the proxy services and would interact with the Service Owners. The policies being SLA, Security, Transformation, Routing, Logging and monitoring.
Service Testers – In this role a user will test and maintain the proxy services in terms of the business requirements as well as runtime policy compliance.
Service Monitoring Representatives: In this role users will monitor all proxy services and help in resolving all SLA related activities.
Anonymous User:
The only exception being that the users:
Will not be responsible for creating Web Services.

Privileges
The roles described above will have CRUD operations on application specific privileges. The identified privileges are, broken down by app category:

Soumadeep Gourangi

Web Services Intermediary features
With the adoption of Web Services in the SOA space WS based intermediaries are gaining importance. The key factors for this adoption are because no matter how Web services are provisioned finally they would be consumed by some applications, the consumption of such services will demand certain functionality which is not related to the service itself, functionalities such as Security, SLA, and Routing for high availability etc.
One could argue that these features could be part of the application that hosts the service. Well, on second thoughts you would agree that all these features would provide more value if isolated and handled by an intermediary.
1) Different application servers which have hosted services can utilize these features rather than implementing such logic.
2) Policy enforcement can be done agnostic of any application server’s native features.
3) Performance would not be hindered due to Application server’s bottle-necks
4) Performance can be managed by dealing with the intermediary
5) The load of processing the components can be separated out and let the Application server handle just the Web services
6) Apart from the additional functions there would be certain maintainability aspects relating to the intermediary such as , handling Policies, data persistence, handling statistics, EPR routing etc
7) Clustering of proxies would serve multiple Applications servers and cater to HA
1.1 Components
1.1.1 Authentication
Authentication details will be taken from a) WS Security Token, b) protocol headers and checked against the following:
SAML assertion
Kerberos tokens
LDAP
Database
File based
1.1.2 Authorization
Depending on the Authentication, user’s groups and roles will be assigned and based on their privileges will allowed to administer the intermediary.
Users: users would belong to a group and share roles.
Group: groups will have roles
Role: roles would have none or many privileges
Privileges: Users can be directly assigned privileges

1.1.3 WS Security – SOAP Based
Security features will be applicable to the SOAP request as well as SOAP response but will also depend whether it’s synchronous or Asynchronous.
Signature
Encryption
Signature Verification
Decryption
Timestamp
CRL
Certification Path validation/Certificate Chain
1.1.4 XML Security
This will be used for XML based services such as REST
1.1.5 SLA – Service Level Agreement
Response time
Priority
Metering
Custom rule based
1.1.6 BAM – Business Activity Monitoring
KPI definition
Rules
Actions
1.1.7 Deprecation
Date time range
Custom rule based
1.1.8 WS-BPEL orchestration
1.1.9 Incentive based contract overriding
Number of hits
Promotion based
Custom rules
1.1.10 Routing
1.1.10.1 Context
Context would depend on the underlying protocol
JMS
HTTP
Email
1.1.10.2 Content
Content evaluation will be on the SOAP message. Evaluation will be based on xpath.
XPath based
Strategies could be Until Success
1.1.10.3 Blind
Random selection of endpoint
1.1.10.4 Parallel
First available service
1.1.10.5 Round Robin
Until success
1.1.10.6 Failover
On Network error, soap fault and timeout; default to the next available service
1.1.10.7 Performance
Cached priority based service endpoint performance
1.1.11 Protocol translator
This feature will act as a protocol translator. This will be applicable in cases where a customer sends a SOAP request using HTTP for a service but the native or endpoint service is say JMS or uses some other protocol.
1.1.12 Content translator
This will be used when the request SOAP or xml needs to be changed. Probable use case would be operation change due to versioning.
1.1.13 Outbound Credential translator
This would be required when the native service requires auth tokens such as WS Security Token, Signed request.
1.2 Services
1.2.1 Embedded SOAP Stack
The embedded SOAP stack could be used to host two types of services:
a) System Services: All system related services such as resource adaptors for integration with application, instrumentation of statistical data.
b) Embedded Web services: For high performance Web services that may be required by clients.

1.2.2 Hot deployment of configuration files
To orchestrate components configuration files need to be hot deployed without affecting requests in the pipeline.
1.2.3 Callback based extension processors
Each component could utilize external components to process the messages. Common cases would be to say eternalize SLA processing.
1.2.4 Polled Extension adaptors
Apart from the intermediary related configuration files some background processes could be required to run on a timely basis.
1.2.5 Service performance statistics
Instrumentation using Web service and MBeans for maintaining state as well as instrumentation.
1.2.6 WS-Notification
Less of acceptance.
1.2.7 Monitoring & Rule based Alerts
SNMP traps
Email
SMS
1.2.8 Logging
Log4j
1.2.9 Events
Service level transaction
System exception
Service level business exception
Intermediary start
Intermediary stop
Service start
Service stop
1.2.10 Reliable Messaging
JMS based reliable message delivery
1.2.11 Resource Adaptors - integration
UDDI interface
Web services interface
Servlet interface
Email interface
1.2.12 Data Persistence
Database
1.2.13 System wide data backup
Rule based
Manual

1.2.14 Clustering
Sharing of resources across clustered intermediaries
1.2.15 Automated endpoint service tweaking
Monitoring and eliminating rouge services – Rule based
1.2.16 PKI management
· Keystore
Maintain keystore for WS-Security and SSL
· Keypair
Manage Keypairs in various keystores
· CRL
To manage Certification Revocation List’s by polling for CRLs from different CAs
1.2.17 MIB Management
Manage MIBs
1.2.18 Intermediary Policy Management
Create and manage service policies

1.3 Bindings
The possible bindings for commonly used protocols are as follows
1.3.1 HTTP
Could be used for synchronous high security based Web service request with WS-security functionalities
1.3.2 HTTPS
Could be used for synchronous low security based Web service request
1.3.3 JMS
Could be used for asynchronous Web service requests
1.3.4 Email
Could be used for asynchronous Web service requests
1.3.5 FTP
Could be used for asynchronous Web service requests
1.4 Technology
1.4.1 SOAP
1.4.2 UDDI
1.4.3 JMS
1.4.4 J2EE
1.4.5 Java
1.4.6 WSDL
1.4.7 WSDM
1.4.8 WS-Security
1.4.9 XML
1.4.10 JMX
1.4.11 RDBMS
1.4.12 Directory Servers
1.4.13 SNMP
1.4.14 SMTP/POP
1.4.15 X509 Certificates
1.4.16 PKI
1.4.17 JAAS

Soumadeep Gourangi

Web Services Intermediary featuresWith the adoption of Web Services in the SOA space WS based intermediaries are gaining importance. The key factors for this adoption are because no matter how Web services are provisioned finally they would be consumed by some applications, the consumption of such services will demand certain functionality which is not related to the service itself, functionalities such as Security, SLA, and Routing for high availability etc.One could argue that these features could be part of the application that hosts the service. Well, on second thoughts you would agree that all these features would provide more value if isolated and handled by an intermediary.1) Different application servers which have hosted services can utilize these features rather than implementing such logic.2) Policy enforcement can be done agnostic of any application server’s native features.3) Performance would not be hindered due to Application server’s bottle-necks4) Performance can be managed by dealing with the intermediary5) The load of processing the components can be separated out and let the Application server handle just the Web services6) Apart from the additional functions there would be certain maintainability aspects relating to the intermediary such as , handling Policies, data persistence, handling statistics, EPR routing etc7) Clustering of proxies would serve multiple Applications servers and cater to HA1.1 Components1.1.1 AuthenticationAuthentication details will be taken from a) WS Security Token, b) protocol headers and checked against the following:SAML assertionKerberos tokensLDAPDatabaseFile based1.1.2 AuthorizationDepending on the Authentication, user’s groups and roles will be assigned and based on their privileges will allowed to administer the intermediary.Users: users would belong to a group and share roles.Group: groups will have rolesRole: roles would have none or many privilegesPrivileges: Users can be directly assigned privileges1.1.3 WS Security – SOAP BasedSecurity features will be applicable to the SOAP request as well as SOAP response but will also depend whether it’s synchronous or Asynchronous.SignatureEncryptionSignature VerificationDecryptionTimestampCRLCertification Path validation/Certificate Chain1.1.4 XML SecurityThis will be used for XML based services such as REST1.1.5 SLA – Service Level AgreementResponse timePriorityMeteringCustom rule based1.1.6 BAM – Business Activity MonitoringKPI definitionRulesActions1.1.7 DeprecationDate time rangeCustom rule based1.1.8 WS-BPEL orchestration1.1.9 Incentive based contract overridingNumber of hitsPromotion basedCustom rules1.1.10 Routing1.1.10.1 ContextContext would depend on the underlying protocolJMSHTTPEmail1.1.10.2 ContentContent evaluation will be on the SOAP message. Evaluation will be based on xpath.XPath basedStrategies could be Until Success1.1.10.3 BlindRandom selection of endpoint1.1.10.4 ParallelFirst available service1.1.10.5 Round RobinUntil success1.1.10.6 FailoverOn Network error, soap fault and timeout; default to the next available service1.1.10.7 PerformanceCached priority based service endpoint performance1.1.11 Protocol translatorThis feature will act as a protocol translator. This will be applicable in cases where a customer sends a SOAP request using HTTP for a service but the native or endpoint service is say JMS or uses some other protocol.1.1.12 Content translatorThis will be used when the request SOAP or xml needs to be changed. Probable use case would be operation change due to versioning.1.1.13 Outbound Credential translatorThis would be required when the native service requires auth tokens such as WS Security Token, Signed request.1.2 Services1.2.1 Embedded SOAP StackThe embedded SOAP stack could be used to host two types of services:a) System Services: All system related services such as resource adaptors for integration with application, instrumentation of statistical data.b) Embedded Web services: For high performance Web services that may be required by clients.1.2.2 Hot deployment of configuration filesTo orchestrate components configuration files need to be hot deployed without affecting requests in the pipeline.1.2.3 Callback based extension processorsEach component could utilize external components to process the messages. Common cases would be to say eternalize SLA processing.1.2.4 Polled Extension adaptorsApart from the intermediary related configuration files some background processes could be required to run on a timely basis.1.2.5 Service performance statisticsInstrumentation using Web service and MBeans for maintaining state as well as instrumentation.1.2.6 WS-NotificationLess of acceptance.1.2.7 Monitoring & Rule based AlertsSNMP trapsEmailSMS1.2.8 LoggingLog4j1.2.9 EventsService level transactionSystem exceptionService level business exceptionIntermediary startIntermediary stopService startService stop1.2.10 Reliable MessagingJMS based reliable message delivery1.2.11 Resource Adaptors - integrationUDDI interfaceWeb services interfaceServlet interfaceEmail interface1.2.12 Data PersistenceDatabase1.2.13 System wide data backupRule basedManual1.2.14 ClusteringSharing of resources across clustered intermediaries1.2.15 Automated endpoint service tweakingMonitoring and eliminating rouge services – Rule based1.2.16 PKI management· KeystoreMaintain keystore for WS-Security and SSL· KeypairManage Keypairs in various keystores· CRLTo manage Certification Revocation List’s by polling for CRLs from different CAs1.2.17 MIB ManagementManage MIBs1.2.18 Intermediary Policy ManagementCreate and manage service policies1.3 BindingsThe possible bindings for commonly used protocols are as follows1.3.1 HTTPCould be used for synchronous high security based Web service request with WS-security functionalities1.3.2 HTTPSCould be used for synchronous low security based Web service request1.3.3 JMSCould be used for asynchronous Web service requests1.3.4 EmailCould be used for asynchronous Web service requests1.3.5 FTPCould be used for asynchronous Web service requests1.4 Technology1.4.1 SOAP1.4.2 UDDI1.4.3 JMS1.4.4 J2EE1.4.5 Java1.4.6 WSDL1.4.7 WSDM1.4.8 WS-Security1.4.9 XML1.4.10 JMX1.4.11 RDBMS1.4.12 Directory Servers1.4.13 SNMP1.4.14 SMTP/POP1.4.15 X509 Certificates1.4.16 PKI1.4.17 JAAS

Soumadeep Gourangi