Your OBIEE Commentary and Collaboration Issues are a Thing of the Past...

As you start 2014 worrying over the issues that plague your BI programme, you can be somewhat comforted by removing one MAJOR headache from the list!

Working with clients since 2006 I've come across requirements for commentary and collaboration functionality native to the BI experience.

Now, for OBIEE, this has been truly solved thanks to a great solution from Christian Screen and the guys at Art of BI.

Not just an app for commentary BITeamwork is a true collaboration platform and since BITeamwork is deployed as its own WebLogic application, it might also be made compatible with other analytical applications in the Oracle Business Intelligence suite. There would be immediate use for BITeamwork in BIPublisher, EPM tools (e.g. Financial Reporting, Workspace) and SmartSuite; though clients will be more than happy with the OBIEE offering.

From OBIEE I've set a dashboard to be my landing page and the collaborative BITeamwork app shows up on the right hand side, ready for my input. It is context and user-sensitive; only my comments and comments shared with me are visible for the specific dashboard (view, cell) I'm currently working on.

Initially my thought is the 'Collaborative BI' app was a bit busy and takes up alot of space... I only want to post comments right??

Not so, I can create comments for dashboards, views and cells; alongside viewing comment history, replies and collaborative threads, as well as secure my comments for specific audiences. I can change the settings, minimize the app to the right, access the help, minimize the app to the bottom (which I really like... below) and sketch on the dashboard page - this last function is REALLY handy for collaboration sessions and web conferences.

For the full range of features, use the 'Comment' prompt at the top of the page, but I wonder if there'll be an auto-hide option in future...?

Entering dashboard comments are saved to the BITeamwork repository as standard, but you can also post to other well-known social applications, Yammer and Chatter. A recent banking client was using IBM Connections, so am sure this authorisation wouldn't be too difficult in future. The same applies for view and cell comments, you can also check a couple of boxes in the 'Settings' menu for comments to be posted to all of these platforms. This is certainly a useful feature, though the level of integration with social platforms could be given more consideration. For example, sharing a bookmark with a Chatter user currently requires the Chatter user to switch over to OBIEE to see the bookmark; passing more information, like 'Briefing Book' style content could avoid a switch between platforms. 

From any dashboard (page) choose the 'Cell or View Highlight' button; switching it on adds a border around the dashboard page sections. Mouseover reveals the options to add a view or dashboard comment.

From a table or pivot view, select an individual cell and a new cell comments box appears. Charts seem to disappear when creating comments for compound views containing charts, using this version, but I'm sure Christian and the team are on top of this. This is not so crucial at the view level, since the comment can be added successfully, but would be more important when / if BITeamwork is able to attach comments to chart data points in OBIEE. 

New administration pages have been added for BITeamwork, so as not to disturb a clients' core installation. This is a good design and couples tightly with the other administration functions in OBIEE. Privileges surrounding BITeamwork functionality are set right alongside OBIEE privileges on a new page tab.

Categories should be tightly controlled, like web catalog foldering, its an area that could get out of hand. They are extremely useful with the current version and might be even more useful if they were security sensitive (e.g. categories for specific application roles).

There's currently no need to use a separate application for BITeamwork administration, as Oracle slowly integrates administration capabilities from previous BI acquisitions into centralised Fusion Middleware utilities though (e.g. Enterprise Manager, Console), I'm sure the guys at ArtofBI will be ahead of the game here.

Overall, its an impressive amount of work that's gone into the application. Its been an area long neglected by Oracle and inadequately addressed by custom developments from numerous third parties.

As a BI consulting shop, or even an independent; if I were you I'd be putting BITeamwork through its paces. It's going to a rip-roaring success, you might just want to be one of those who knows how to install it for your clients.

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

Development Costs and Technical Confidence...

Micro-management is often the adversary of creativity and progress; with progress constrained by the rate at which the micro-manager reaches their own level of comfort and understanding.

This applies to technology (software) programmes, even the implementation of pre-pack solutions like OBIA!

For the manager, it's important to understand the RELATIVE impact of software development challenges, when you're delivering solutions driven by software. Why the problem is easy or why it is hard, has a profound impact on programme planning and budgets.

This can greatly increase cost for enterprise programmes, increasing the cash burn rate. For a start up, getting this wrong can be fatal!

Modern day project management methodologies must shoulder some of the blame for producing the pure 'Microsoft Project jockey', but the better manager develops a certain curiosity for software solutions that makes them more able to anticipate difficulties ahead.

As a non-technical manager in these situations, a level of questioning for your development staff is crucial. Try not to make the questioning static, like the real exchange I had recently with a client below:

Manager: That looks technical, what are you doing?
Developer: I'm re-purposing the scripts so they work in both non-clustered and clustered environments!
Manager: That's not something I can help you with, sorry.
Developer: Err... no I guess not!

Questions should be designed to tease out why certain tasks in the solution are important and how they contribute to the overall solution. A better set of questions might have been:

Manager: I understand you're working on X, is that what you're doing just there?

Developer: Not X just now, I'm working on re-purposing the scripts so they work in both clustered and non-clustered environments.

Manager: OK, I'm a little unfamiliar with that work. It sounds important, perhaps you can tell me more about the implications of this?

Developer: Sure... BLAH BLAH BLAH  
 

This level of questioning is extremely important for good project (programme) management!

Once the manager becomes confused by technical complexity, however, they revert to questioning the validity of technical tasks in a plan (solution). This level of questioning can be a waste of time!

As a non-technical manager (read start up CEO working with technical staff), keep in mind what are you trying to achieve by asking these questions...

    - enough understanding of the challenges in your project (programme)

    - a greater appreciation of the capabilities of your technical staff

    - greater control of cost

Recognise, however, once technical aspects become unclear this makes them NO LESS valid. Better developers will have some understanding of the planning and costs you're trying to control.

Keep your questioning open and you'll gain the trust of your developers!

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

Due Diligence for Enterprise Software Programmes...

A recent client had some of the usual problems which come with large enterprise software implementations, here's my take on some improvements to consider:

1. Too many systems integrators (SIs) - if, like economic theory, we assume free trade benefits all parties then maintaining open exchange of ideas and expertise is crucial; recognising the enterprise programme will benefit only through collaboration amongst dependent parties. Theoretically many SIs on a project should compete away differences to leave an implementation of the greatest benefit to the client, but this has long been disproved by the 'power elite' theory. Most often SIs seek absolute power advantage over one another in their relationship with the client. Projects suffer, not just economically, where the client is unclear with SIs over division of roles...

2. Off-shoring tasks on the critical path in a development lifecycle - this can work, but importantly the offshore team should have some understanding of the business area for whom they are developing, the stronger the better. As a programme management team the answers to the following questions about the capabilities of your off-shoring team are helpful to clarify:

• If using an SI off-shore, are their goals suitably aligned with the programme?
• Where difficult development challenges arise, can the offshore team think critically to resolve them?
• Are their solutions of genuine benefit to the client?
• Are you getting them for the right price?
• Even if you've answered 'Yes' to these questions, ask yourself 'Does all this sound too good to be true?'

There's a distinctly Marxist undertone to the off-shoring phenomena. As an employee of the SI assigned to the client, it's understandable you might begin to feel a little exploited where its clear the singular reason for your presence is cost reduction; but poor alignment of goals produces low productivity; while rising wages in traditionally offshore locations are forms of worker revolt.

An offshore strategy can become increasingly difficult to justify...

3. Hand-offs between competing SIs engaged in the release and testing process - competing systems integrators were engaged to separately handle release and configuration management, where initially there had been one. These ITIL aspects of any programme are so closely related, introducing a hand-off in this area mostly adds time, without bringing efficiency; while the use of competing SIs here brings an unnecessary period of professional 'sabre-rattling' as all parties are encouraged to get along well for the benefit of the client. Keep it simple here; there are hidden costs in too many hand-offs!

4. When the going gets tough, which team members stand up - under time pressure, or faced with challenging tasks is the client still able to rely on all the team members to continue getting the job done? It's under these circumstances the quality of staff is revealed:

• Do they look for the right answer, or the quick answer? These are often not the same.
• Can they produce suitable quality despite added pressure?
• Is the work well documented and
• Can they still transfer the knowledge to others?

5. SIs over-stating the capabilities of their consultants (that never happens ;-) ) - Sales and the 'spin' surrounding the capabilities your SI can deliver are part of the territory, but, like hiring employees, the client would do well to consider ways of testing the consultants they end up saddled with:

• Despite the sales pitch, does the individual consultant have the basic skills required?
• How well do the consultants interpret the information provided to them?
• When confronted with a challenge would the consultant choose the 'quick fix' or the 'best fix'?

Finally, question if the client has the right skills to competently assess the quality of the consultant. Without that, your programme will be in trouble.

Its important to remember that Adam Smith's view of capitalism - where the individual rises above their self-interest for the benefit of others - does not apply here. You'd do we'll to get an unbiased view when starting your programme.

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

Herding Cats -> OBI EE Deployments in 11G

If you've come from a 10G / Siebel Analytics background you could be forgiven for thinking that managing your 11G environment(s) is a bit like herding cats.

There's a new file over here, another service over there and any number of utilities scattered in the 11G directory forest; the trick is bringing them all together for a smooth deployment process.

Core development activity is mostly unchanged (Catalog or Repository, some Publisher), but security administration is much more comprehensive. Firstly, it is in at least 3 places:

• policy store,
• catalog,
• repository, then
• a fourth if you've OIM / OAM installed (user to group mappings)

Secondly, added security in the repository (repository password) means a straight replacement of this file on the <TARGET> is not always the correct option. Catalog privileges have always been in the '/system' subfolder of the catalog, but their location means there are specific considerations for deployment using web catalog utilities.


Industries with particular security requirements (banking, defence, security services) will welcome these added security features, but for release and deployment it means extra steps.

Recently my concentration has been on efficient deployment; scripting as many of these steps as possible to keep deployment time to a minimum, all the while keeping track of the deployed version on each of the target environments.

Venkat highlighted some 11G migration challenges a while back, while John M. put together samples of scripting with WebLogic (WLST). 

Getting deployment steps right is crucial to being nimble on large scale deployments. Key considerations are:

When dealing with a lot of environments get into some good practices around version management for your components (where possible). For example:

Rough steps for a core OBI 11G deployment process are outlined in the diagram.

N.B. Back-up of core components should be considered as part of any deployment process.These tasks are not depicted.

Midvision, for example, also think deployment shouldn't be a drag for any project and are successfully commercializing the deployment process.

What's this all got to do with front-end components?. Well, it's 'runcat', correct and efficient catalog deployment ('runcat')! We'll look briefly at 'runcat' in the next post.


Sorry this entry has been so long, unlike me...

DR. OBI