Category Archives: Rittman Mead
The best OBIEE 12c feature that you’re probably not using.
With the release of OBIEE 12c we got a number of interesting new features on the front-end. We’re all talking about the cleaner look-and-feel, Visual Analyzer, and the ability to create data-mashups, etc.
While all this is incredibly useful, it’s one of the small changes you don’t hear about that’s truly got me excited. I can’t tell you how thrilled I am that we can finally save a column back to the web catalog as an independent object (to be absolutely fair, this actually first shipped with 11.1.1.9).
For the most part, calculations should be pushed back to the RPD. This reduces the complexity of the reports on the front-end, simplifies maintenance of these calculations, and ultimately assures that the same logic is used across the board in all dashboards and reports… all the logic should be in the RPD. I agree with that 110%… at least in theory. In reality, this isn’t always practical. When it comes down to it, there’s always some insane deadline or there’s that pushy team (ahem, accounting…) riding you to get their dashboard updated and migrated in time for year end, or whatever. It’s quite simply just easier sometimes to just code the calculation in the analysis. So, rather than take the time to modify the RPD, you fat finger the calculation in the column formula. We’ve all done it. But, if you spend enough time developing OBIEE reports and dashboards, sooner or later you’ll find that this is gonna come back to bite you.
Six months, a year from now, you’ll have completely forgotten about that calculation. But there will be a an org change, or a hierarchy was updated… something, to change the logic of that calculation and you’ll need make a change. Only now, you know longer remember the specifics of the logic you coded, and even worse you don’t remember if you included that same calculation in any of the other analyses you were working on at the time. Sound familiar? Now, a change that should have been rather straightforward and could have been completed in an afternoon takes two to three times longer as you dig through all your old reports trying to make sense of things. (If only you’d documented your development notes somewhere…)
Saving columns to the web catalog is that middle ground that gives us the best of both worlds… the convenience of quickly coding the logic on the front-end but the piece of mind knowing that the logic is all in one place to ensure consistency and ease maintenance.
After you update your column formula, click OK.
From the column dropdown, select the Save Column As option.
Save the column to the web catalog. Also, be sure to use the description field. The description is a super convenient place to store a few lines of text that your future self or others can use to understand the purpose of this column.
As an added bonus, this description field is also used when searching the web catalog. So, if you don’t happen to remember what name you gave a column but included a little blurb about the calculation, all is not lost.
Saved columns can be added from the web catalog.
Add will continue to reference the original saved column, so that changes to made to the saved column will be reflected in your report. Add Copy will add the column to your report, but future changes to the saved column will not be reflected.
One thing to note, when you add a saved column to a report it can no longer be edited from within the report. When you click on Edit Formula you will still be able to see the logic, but you will need to open and edit that saved column directly to make any changes to the formula.
Try out the saved columns, you’ll find it’s invaluable and will greatly reduce the time it takes to update reports. And with all that free time, maybe you’ll finally get to play around with the Visual Analyzer!
The post The best OBIEE 12c feature that you’re probably not using. appeared first on Rittman Mead Consulting.
OBIEE12c – Three Months In, What’s the Verdict?
I’m over in Redwood Shores, California this week for the BIWA Summit 2016 conference where I’ll be speaking about BI and analytics development on Oracle’s database and Hadoop platforms. As it’s around three months now since OBIEE12c came out and we were here for Openworld, I thought it’d be a good opportunity to reflect on how OBIEE12c has been received by ourselves, the partner community and of course by customers. Given OBIEE11g was with us for around five years it’s still early days in the overall lifecycle of this release, but it’s also interesting to compare back to where we were around the same time with 11g and see if we can spot any similarities and differences to take-up then.
Starting with the positives; Visual Analyzer (note – not the Data Visualization option, I’ll get to that later) has gone down well with customers at least over in the UK. The major selling point seems to be “Tableau with a shared governed data model and integrated with the rest of our BI platform” (see Oracle’s slide from Oracle Openworld 2015 below), and given that the DV option’s price point per named-used seems to be comparable with Tableau server the cost-savings in terms of not having to learn and support a new platform means that customers seem pleased this new feature is now available.
Given that VA is an extra-cost option what I’m seeing is customers planning to upgrade their base OBIEE platform from 11g to 12c as part of their regular platform refresh schedule, and then postponing the VA part until after the upgrade and as part of a separate cost/benefit exercise. But VA seems to be the trigger for customers to start considering an upgrade now, with the business typically now holding the budget for BI and Visual Analyzer (like Mobile with 11g) being the new capability that unlocks the upgrade spend.
On the negative side, Oracle charging for VA hasn’t gone down well, either from the customer side who ask what it is they actually get for their 22% upgrade and maintenance fee if they they have to pay for anything new that comes with the upgrade; or from partners who now see little in the 12c release to incentivise customers to upgrade that’s not an additional cost option. My response is usually to point to previous releases – 11g with Scorecards and Mobile, the database with In-Memory, RAC and so on – and say that it’s always the case that anything net-new comes at extra cost, whereas the upgrade should be something you do anyway to keep the platform up-to-date and be prepared to uptake new features. My observation over the past month or so is that this objection seems to be going away as people get used to the fact that VA costs extra; the other push-back I get a lot is from IT who don’t want to introduce data mashups into their environment, partly I guess out of fear of the unknown but also partly because of concerns around governance, how well it’ll work in the real world, so on and so on. I’d say overall VA has gone down well at least once we got past the “shock” of it costing extra, I’d expect there’ll be some bundle along the lines of BI Foundation Suite (BI Foundation Suite Plus?) in the next year or so that’ll bundle BIF with the DV option, maybe include some upcoming features in 12c that aren’t exposed yet but might round out the release. We’ll see.
The other area where OBIEE12c has gone down well, surprisingly well, is with the IT department for the new back-end features. I’ve been telling people that whilst everyone thinks 12c is about the new front-end features (VA, new look-and-feel etc) it’s actually the back-end that has the most changes, and will lead to the most financial and cost-saving benefits to customers – again note the slide below from last year’s Openworld summarising these improvements.
Simplifying install, cloning, dev-to-test and so on will make BI provisioning considerably faster and cheaper to do, whilst the introduction of new concepts such as BI Modules, Service Instances, layered RPD customizations and BAR files paves the way for private cloud-style hosting of multiple BI applications on a single OBIEE12c domain, hybrid cloud deployments and mass customisation of hosted BI environments similar to what we’ve seen with Oracle Database over the past few years.
What’s interesting with 12c at this point though is that these back-end features are only half-deployed within the platform; the lack of a proper RPD upload tool, BI Modules and Services Instances only being in the singular and so on point to a future release where all this functionality gets rounded-off and fully realised in the platform, so where we are now is that 12c seems oddly half-finished and over-complicated for what it is, but it’s what’s coming over the rest of the lifecycle that will make this part of the product most interesting – see the slide below from Openworld 2014 where this full vision was set-out, but in Openworld this year was presumably left-out of the launch slides as the initial release only included the foundation and not the full capability.
Compared back to where we were with OBIEE11g (11.1.1.3, at the start of the product cycle) which was largely feature-complete but had significant product quality issues, with 12c we’ve got less of the platform built-out but (with a couple of notable exceptions) generally good product quality, but this half-completed nature of the back-end must confuse some customers and partners who aren’t really aware of the full vision for the platform.
And finally, cloud; BICS had an update some while ago where it gained Visual Analyzer and data mashups earlier than the on-premise release, and as I covered in my recent UKOUG Tech’15 conference presentation it’s now possible to upload an on-premise RPD (but not the accompanying catalog, yet) and run it in BICS, giving you the benefit of immediate availability of VA and data mashups without having to do a full platform upgrade to 12c.
In-practice there are still some significant blockers for customers looking to move their BI platform wholesale into Oracle Cloud; there’s no ability yet to link your on-premise Active Directory or other security setup to BICS meaning that you need to recreate all your users as Oracle Cloud users, and there’s very limited support for multiple subject areas, access to on-premise data sources and other more “enterprise” characterises of an Oracle BI platform. And Data Visualisation Cloud Service (DVCS) has so far been a non-event; for partners the question is why would we get involved and sell this given the very low cost and the lack of any area we can really add value, while for customers it’s perceived as interesting but too limited to be of any real practical use. Of course, over the long term this is the future – I expect on-premise installs of OBIEE will be the exception rather than the rule in 5 or 10 years time – but for now Cloud is more “one to monitor for the future” rather than something to plan for now, as we’re doing with 12c upgrades and new implementations.
So in summary, I’d say with OBIEE12c we were pleased and surprised to see it out so early, and VA in-particular has driven a lot of interest and awareness from customers that has manifested itself in enquires around upgrades and new features presentations. The back-end for me is the most interesting new part of the release, promising significant time-saving and quality-improving benefits for the IT department, but at present these benefits are more theoretical than realisable until such time as the full BI Modules/multiple Services Instances feature is rolled-out later this year or next. Cloud is still “one for the future” but there’s significant interest from customers in moving either part or all of their BI platform to the cloud, but given the enterprise nature of OBIEE it’s likely BI will follow after a wider adoption of Oracle Cloud for the customer rather than being the trailblazer given the need to integrate with cloud security, data sources and the need to wait for some other product enhancements to match on-premise functionality.
The post OBIEE12c – Three Months In, What’s the Verdict? appeared first on Rittman Mead Consulting.
Upgrade to ODI 12c: Repository and Standalone Agent
This is my first post, and I hope to have many more to come. My name is Brian Sauer, and I am fairly new here at Rittman Mead and proud to be here. I have close to 5 years of experience with Oracle Data Integrator, both 10g and 11c. I have been involved in ETL activities for close to 8 years. Prior to using Oracle Data Integrator, most of my activities in ETL utilized Perl. Ever since being exposed to Oracle and ODI, I have found a home that has been both comforting and challenging. It is a passion of mine to be able to work with any type of database and to get data from point A to point B, making the necessary changes to get user’s hands on it in a meaningful and useful way. Thus, I’ve put together this blog post to assist with the upgrade of ODI 11g to ODI 12c. I hope it’s useful to you.
After going through the process of upgrading from ODI 11g to ODI 12c, I found the documentation to be scattered around a bit and began putting together a roadmap of the information that was vital to the upgrade itself. This post is essentially a brief explanation of some added enhancements to ODI in 12.1.3.0 and a straightforward guide to the upgrade process. I’m not addressing 12.2.1.0 in this post, as many of our clients have been moving to 12.1.3.0 due to stability and testing issues with 12.2.1.0. I will take a look 12.2.1.0 in my next post in this series.
ODI 12.1.3.0 was released in November 2014, and along with it came a number of enhancements and significant changes from ODI 11.1.1.7.0. I am going to focus on the upgrade process with this post and some of the more significant changes.
According to the Oracle documentation, the only supported starting points for upgrading to ODI 12c (12.1.3) are the following:
- Oracle Data Integrator 11g Release 1 (11.1.1.6.0)
- Oracle Data Integrator 11g Release 1 (11.1.1.7.0)
There are some significant changes to ODI from 11g. First and foremost is the way that the agents are handled in 12c. Standalone Agents are now managed by the WebLogic Management Framework, and they are installed in their own directories. Also, interfaces have given way to mappings and reusable mappings. Lastly, the repository upgrade to 12.1.3 validates name uniqueness for objects such as interfaces, folders, procedures, knowledge modules, packages, and profiles. If duplicates exist, the upgrade process will check for it, and you can print a report that will list the duplicates in the upgrade log. You’ll then need to reopen ODI 11g and manually fix the duplicates and restart the upgrade.
Below is a comparison of the ODI JEE Agent Upgrade topology. Notice that in 12c only an LDAP-based store can be used for OPSS as file-based stores are no longer allowed.
You’ll also notice the topology for Standalone Agents not registered with a WebLogic Domain have changed as mentioned earlier; they are now part of the WebLogic Management Framework. The agent is configured in a standalone domain unlike its predecessor in 11g.
For Standalone Agents in 11g that were registered with a WebLogic Domain nothing has really changed from a topology standpoint as shown below:
Some considerations to take into account before diving into the upgrade are the following:
- Verify that the database which will host the schemas required by Fusion Middleware is supported. You can verify at: http://docs.oracle.com/middleware/1213/core/ODIUG/tasklist.htm#BABGAIFA
- ODI 12.1.3 requires a 64-bit operating system. Verify your machine is 64-bit, and, if not, then upgrade.
- Verify you are running a supported version (11.1.1.6, 11.1.1.7).
- Develop a backup and recovery strategy.
- Plan for system downtime during the upgrade process.
Upgrade Process
BACKUPS
The first and probably most important step before you even begin the upgrade is to make sure you have a solid backup of your 11g environment. There are many ways to do this, but you will want to make sure that you have a backup of the following so you can restore your prior environment in the event that a failure occurs:
- ODI Home Directory
- ODI Work Repository(s)
- ODI Master Repository
To preserve the ODI 11g Home Directory, I simply make a copy of the ODI_HOME directory, zip it up, and save in another location. To preserve the ODI Master and Work Repositories, simply use the export utility within ODI.
This will provide a saved copy of each. In addition to the backup, record the Repository IDs in the event you need to restore. Lastly, I create a database backup of the ODI schemas that will be upgraded. These are the schemas where the Master and Work Repositories reside.
Zero or Limited Downtime Approaches
An important question is, How can I upgrade my system with limited or even zero downtime?
Oracle recommends cloning the work and master repositories on your database in another database instance and then upgrading the cloned repositories. This will keep your current 11g repositories active and untouched during the upgrade process, and once the upgrade is complete and you’ve been able to test it out, you can switch to the new 12c repositories as your active ODI implementation. Oracle has provided sample scripts for different database environments at the following location:
https://docs.oracle.com/middleware/1212/odi/ODIUG/tasklist.htm#ODIUG117
As a part of your testing you will want to verify, after you have set up your cloned repositories, that the cloned master repository points to the correct work repository(s). Also, as a part of cloning the repositories, you’ll need to copy the row about the master repository in SYSTEM.SCHEMA_VERSION_REGISTRY$ from the old to the new instance. This is not a supported change by Oracle, however it is required for the upgrade to be successful.
Another upgrade option other than cloning is to create a brand new ODI 12c repository on your database and then export your objects from 11g and import them individually to your new 12c repository using ODI Studio. To perform this task you’ll need to use the upgrade key which is new to 12c and which I’ve explained later in this post for the imports. This is not my recommended approach as it takes longer and is more tedious which can lead to missed objects during the export/import process.
However, if you choose to go this route, the export/import order I have used in the past is the following:
- Topology
- Models
- Global Objects
- Projects
Installing Oracle Data Integrator 12c Products
Now that backups have been made and we are confident that in the event of an unsuccessful upgrade we can recover and we have decided on a transition strategy, it is time to begin installing our 12c products.
We have a couple questions to answer first. Are we upgrading with a Standalone Agent or a Java EE Agent? If we are installing an environment with a Java EE Agent then we will need to download two separate files from Oracle:
- Oracle Data Integrator 12cR1 (12.1.3.0.0) for all platforms install file.
- Oracle Fusion Middleware Infrastructure (for All Platforms).
If we are installing for a standalone environment which we are in this post, then the second file is not required or needed. You will need approximately 1.5GB of space for the home directory where you install ODI 12c. I would recommend an additional 1GB of space to account for domains for agents. The following link will give you the ODI 12c Studio installation instructions in detail:
https://docs.oracle.com/middleware/1212/odi/ODING/install.htm#ODING286
Creating/Upgrading the Master and Work Repositories
Now that ODI 12c Studio is installed, we’ll need to create the Master and Work repositories in the database so that they can effectively communicate with ODI 12c Studio. To do this you’ll need to navigate to the <ODI_HOME>/oracle_common/bin directory and run either ./rcu.sh or rcu.bat, depending on your environment.
Before beginning the creation of the 12c repositories, make sure you have a solid backup of the 11g repositories.
You’ll want to make sure that you have DBA privileges for this step as you’ll be creating new schemas and tables in the database that will require these permissions. The wizard does give you the option of creating the scripts for the DBA to use later if necessary, although it may be best to work with the DBA directly as you create the repositories.
First, you will want to choose an existing prefix since this is how you identify the repository to be upgraded in the DB.
Secondly, you’ll need to check off the following components to identify them in your 12c upgrade:
- Oracle AS Repository Components/AS Common Schemas/Common Infrastructure Services which creates the new *_STB schema for 12c.
- Oracle Data Integrator/Master and Work Repository
As you enter the schema passwords and mapping information, the utility will ultimately reach the summary screen where it will show you the new schemas it will create. If any schemas have already been created, be aware that they will not be listed here since they do not need to be created again. At this screen, you click create, and the creation of the new schemas/components will commence.
Once you have created the new schemas necessary for 12c, we will start the Upgrade Assistant so the previous version of ODI can be upgraded to 12.1.3.0.0. You will find the upgrade assistant at:
<ODI_HOME>/oracle_common/upgrade/bin
You’ll execute the ua.bat or ua file depending on your environment.
When asked what type of upgrade you wish to perform, you will want to select “Schemas” as this will allow you to identify the schemas where the upgrade will take place.
The upgrade assistant will then list the schemas available to upgrade. When asked what components to upgrade, you will select “Oracle Data Integrator”.
The only other item that I’d draw your attention to is the screen providing the “Upgrade Key”. This key is used to convert 11g object IDs into unique GUIDs. You will want to save this key as you will need this for additional 11g objects that may need to be imported at a later time. This key allows ODI to consistently calculate the same GUID for an 11g object when importing to 12c. The key identifies uniquely the set of repositories that were working together before an upgrade. Since the 12c repository has switched to using GUIDs to better guarantee unique ID’s, the 11g ID will not work without providing the upgrade key.
As you upgrade to 12c, the question will likely arises as to why would you need this upgrade key. The situation may arise where you would need to restore an object, import a scenario, or revert back to a prior topology. This key will allow you to do so with your 11g exports.
Once completion of the Upgrade Assistant has occurred, you will want to verify that the version of ODI has been updated in the schema. You can run the following command to verify:
SELECT OWNER, VERSION, STATUS FROM SCHEMA_VERSION_REGISTRY WHERE OWNER = ‘<prefix>_ODI_REPO’;
You should see the version for your schema as: 12.1.3.0.0 with a status of ‘VALID’
Creating the Standalone Agent
Our final step is creating the Standalone Agent. As I wrote earlier, this has changed with 12c since the WebLogic framework is being used now for all agents. Due to this, you cannot upgrade 11g standalone agents to 12c, and you will need to create new ones.
We will place our new Standalone Agent in a domain folder which will sit outside of the ODI_HOME.
To create the Standalone Agent, navigate to ODI_HOME/oracle_common/common/bin and execute either config.sh or config.exe based on your operating system.
The first screen that you will come across will ask you to either create a new domain or update an existing domain. In our case here, we did not have an existing domain so we will create a new Standalone Agent Domain. The wizard will default to a location within your ODI_HOME. You will want to change this location so that it resides OUTSIDE the ODI_HOME as I wrote earlier. The reason for this is that in the future it could create problems for upgrading your ODI software if the domain is created in the ODI_HOME.
The rest of the steps are straightforward. You’ll choose to create the “Oracle Data Integrator – Standalone Agent – 12.1.3.0[odi]”, enter database configuration information, and choose a user name and password for the Node Configuration. Then, you will be prompted to create your agent.
Once you have completed these steps to start the agent, go to DOMAIN_HOME/bin and select either startNodeManger.cmd or startNodeManager.sh depending on your operating system. You’ll be prompted to enter the credentials you chose when configuring the node above.
Once you’ve completed these steps, you’ll go through the process of creating your agent within ODI Studio both within the Physical and Logical Architecture.
Then run the following command depending on your operating system:
./agent.sh –NAME=<AGENT_NAME>
agent.cmd –NAME=<AGENT_NAME>
Once these commands have executed successfully you’ll want to confirm the agent is running without issue by clicking on the “Test” button by opening the agent you created in the Physical Architecture in ODI Studio.
I would shut down and remove the agent that existed in your 11g environment as you remove the 11g ODI home directory. Remember in our backup that we zipped a copy of the 11g home directory and stored it in another location. Once you have confirmed that ODI 12c is operating as expected, you may remove this directory if it’s on the same server.
Testing, Upgrade Issues, and Clean Up
The approach that I have used when testing has been to test each individual interface and load plan against the results in its 11g counterpart. I verify the counts initially and then have the users/owners verify the data. I then allow the load plans to run a few days to a week, and once the users/owners are comfortable with the results, migrate to the new implementation.
That being said, the following issues and clean up items may need to be addressed, which I and some of my colleagues at Rittman Mead have encountered while upgrading to 12c:
- Variables in mappings/KMs are not recognized by the parser when creating scenarios, so they are not recognized as input parameters. Consequently, you’ll want to wrap each mapping in a package or load plan with the variables declared in it.
- The variables are case-sensitive in 12c, so if you called a variable with a different case in a mapping, you will need to change it to the matching case.
- Make sure to prefix all variables with the project code or global.
- Do not start any data store alias with a number as this does not work well in 12c.
- Temporary interfaces from 11g are triplicated in 12c during the upgrade and require cleanup in projects as well as the models. The upgrade creates these as a regular mapping and creates a target table in the models which can be removed. It also creates two copies of each temporary interface in Reusable Mappings with suffixes of RMS (Re-usable Mapping Source) and RMT (Re-usable Mapping Target). For the most part the RMT reusable mappings can be removed, however verify the mapping(s) using the temporary interface are suffixed by RMS before deleting.
- Upgrade the mappings to flow-based using “Convert to Flow” on the dataset. (Optional)
- You can check out Michael Rainey’s post on this at: http://www.rittmanmead.com/2015/04/di-tips-odi-convert-to-flow/
In my next post, I will go over the process that involves upgrading the Java EE Agent to 12c from 11g and highlight where the upgrade to 12.2.1.0 differs from the upgrade to 12.1.3.0. Stay tuned!
The post Upgrade to ODI 12c: Repository and Standalone Agent appeared first on Rittman Mead Consulting.
Mike Hibbert – A Celebration
It’s been a long while since I graced the blog with my presence and I had always hoped that when I did return, it would be with something new, or exciting to say. Instead, I find myself writing something much more personal and subdued: a celebration of one of our dear colleagues who, after a 2 year fight, lost his battle to cancer just before Christmas 2015.
Joining us in September 2010, Mike Hibbert was one of our longest serving team members. We still don’t have too many people with over 5 years service, but Mike was one of us. I was lucky enough to work with Mike from day one: he was parachuted into the project I was working on to cover the large gaps in my OWB knowledge and experience. His role on the project was not that of simply building some mappings (we were already 7 months into the 9 month engagement and the OWB estate had already been built). Instead, Mike’s task was to mentor the clients OWB team and ensure their ETL development capability was in place. At the same time, he had to come to terms with the OWB estate, review it and where necessary, make it production-ready. Landing on a project late in the day is never an enviable task for us consultants…even more so when it is your first day on the new job!
Mike brought bags of technical experience in both OWB and OBIEE from his previous roles with Edenbrook & Hitachi Consulting, but what impressed me most about Mike in that first project was the way he built up such a good rapport with all the members of the clients diverse project team. He gained the teams trust on the technical side early but also engaged with people at a very personal level. His approach was friendly and easy-going and he would always show an active interest in everything about the people he was working with, be it understanding their perspective on a particular technical challenge or simply talking about last nights TV, major family milestones or the travails of our chosen football teams. His sense of humour was disarming and his natural approach stood him in very good stead throughout his time with Rittman Mead.
Mike spent most of his time with us working on the continent, initially in Belgium, but in 2011 he began working with one of our major clients in the Netherlands. This was the start of a long and valued relationship with the client, where Mike fulfilled several roles, mainly around OBIEE but also getting his hands increasingly dirty with APEX! The scope of the projects and the personnel involved changed over time, but Mike was a constant. He championed new agile delivery methods and became a key member of the clients team, delivering a number of critical solutions to their business units across Europe. All told, Mike worked with the same client for over 4 years – a mark of his value and importance to them. He continued to work through his illness and treatment, taking very little time off. He was still working into his final week. I came to learn that this was how Mike wanted to tackle his illness and the courage and determination he showed in facing it in this way is an inspiration to us all.
Mike was a vital member of our team. He was a founding father of the Rittman Mead Fantasy Football League, now in its 4th year and, although he never admitted it, I think he was always a little frustrated that he never won the title. I always looked forward to the start of each season in anticipation of the interesting team names Mike always seemed to come up with…often cryptic, always cheeky and always guaranteed to raise a chuckle! As a Manchester United fan, we could always rely on Mike to give us his hints and tips on which of the Red Devils we should have in our teams…occasionally, his advice even made some sense! Mike’s main interests lay in sport. He kept the illustrious tennis career he had before entering the BI world under wraps for quite a while, but his main pursuits were running and cycling – two things that he put together (with a swim beforehand for good measure) to compete in the occasional triathlon. Amazingly, he continued his cycling through his illness, raising money for both Prostate Cancer UK and The Christie. In proposing a UK vs Rest of the World 5-a-side match, little did Mike know that he would initiate the companies longest e-mail debate. It caught our imagination and we had our first match during our BI Forum in 2013. Mike played on the Rest of the World side (justified by his working relationship with the Netherlands!) and despite giving away a few years on us all, he duly earned the Man of the Match award. I hope that we will be able to continue these 5-a-side battles in his memory for years to come.
On a personal level, Mike and I lived relatively close to each other and for a period, this meant us sharing flights to/from Manchester airport. We spent some very early mornings in MAN departures and many an hour waiting for delayed flights from AMS (and inevitably enjoying the odd continental beer!). We coincidentally earned our FA Level 1 coaching badges at the same time and each of us coached our own sons teams. Our conversations would always eventually turn into a discussion of recent results, tactics and training methods…just another example of Mike’s personable style and his interest in others.
Mike will be sadly missed as a friend and colleague and the collective thoughts and support of Rittman Mead go out to the family that he leaves behind.
We are keen to lend our efforts to the amazing charitable efforts that Mike started and his family continues. We have some fund-raising ideas, which I think Mike would appreciate and I hope can come to fruition in the near future. In the meantime, if you knew or worked with Mike it would be great to hear your memories of him.
The post Mike Hibbert – A Celebration appeared first on Rittman Mead Consulting.
Mike Hibbert – A Celebration
It’s been a long while since I graced the blog with my presence and I had always hoped that when I did return, it would be with something new, or exciting to say. Instead, I find myself writing something much more personal and subdued: a celebration of one of our dear colleagues who, after a 2 year fight, lost his battle to cancer just before Christmas 2015.
Joining us in September 2010, Mike Hibbert was one of our longest serving team members. We still don’t have too many people with over 5 years service, but Mike was one of us. I was lucky enough to work with Mike from day one: he was parachuted into the project I was working on to cover the large gaps in my OWB knowledge and experience. His role on the project was not that of simply building some mappings (we were already 7 months into the 9 month engagement and the OWB estate had already been built). Instead, Mike’s task was to mentor the clients OWB team and ensure their ETL development capability was in place. At the same time, he had to come to terms with the OWB estate, review it and where necessary, make it production-ready. Landing on a project late in the day is never an enviable task for us consultants…even more so when it is your first day on the new job!
Mike brought bags of technical experience in both OWB and OBIEE from his previous roles with Edenbrook & Hitachi Consulting, but what impressed me most about Mike in that first project was the way he built up such a good rapport with all the members of the clients diverse project team. He gained the teams trust on the technical side early but also engaged with people at a very personal level. His approach was friendly and easy-going and he would always show an active interest in everything about the people he was working with, be it understanding their perspective on a particular technical challenge or simply talking about last nights TV, major family milestones or the travails of our chosen football teams. His sense of humour was disarming and his natural approach stood him in very good stead throughout his time with Rittman Mead.
Mike spent most of his time with us working on the continent, initially in Belgium, but in 2011 he began working with one of our major clients in the Netherlands. This was the start of a long and valued relationship with the client, where Mike fulfilled several roles, mainly around OBIEE but also getting his hands increasingly dirty with APEX! The scope of the projects and the personnel involved changed over time, but Mike was a constant. He championed new agile delivery methods and became a key member of the clients team, delivering a number of critical solutions to their business units across Europe. All told, Mike worked with the same client for over 4 years – a mark of his value and importance to them. He continued to work through his illness and treatment, taking very little time off. He was still working into his final week. I came to learn that this was how Mike wanted to tackle his illness and the courage and determination he showed in facing it in this way is an inspiration to us all.
Mike was a vital member of our team. He was a founding father of the Rittman Mead Fantasy Football League, now in its 4th year and, although he never admitted it, I think he was always a little frustrated that he never won the title. I always looked forward to the start of each season in anticipation of the interesting team names Mike always seemed to come up with…often cryptic, always cheeky and always guaranteed to raise a chuckle! As a Manchester United fan, we could always rely on Mike to give us his hints and tips on which of the Red Devils we should have in our teams…occasionally, his advice even made some sense! Mike’s main interests lay in sport. He kept the illustrious tennis career he had before entering the BI world under wraps for quite a while, but his main pursuits were running and cycling – two things that he put together (with a swim beforehand for good measure) to compete in the occasional triathlon. Amazingly, he continued his cycling through his illness, raising money for both Prostate Cancer UK and The Christie. In proposing a UK vs Rest of the World 5-a-side match, little did Mike know that he would initiate the companies longest e-mail debate. It caught our imagination and we had our first match during our BI Forum in 2013. Mike played on the Rest of the World side (justified by his working relationship with the Netherlands!) and despite giving away a few years on us all, he duly earned the Man of the Match award. I hope that we will be able to continue these 5-a-side battles in his memory for years to come.
On a personal level, Mike and I lived relatively close to each other and for a period, this meant us sharing flights to/from Manchester airport. We spent some very early mornings in MAN departures and many an hour waiting for delayed flights from AMS (and inevitably enjoying the odd continental beer!). We coincidentally earned our FA Level 1 coaching badges at the same time and each of us coached our own sons teams. Our conversations would always eventually turn into a discussion of recent results, tactics and training methods…just another example of Mike’s personable style and his interest in others.
Mike will be sadly missed as a friend and colleague and the collective thoughts and support of Rittman Mead go out to the family that he leaves behind.
We are keen to lend our efforts to the amazing charitable efforts that Mike started and his family continues. We have some fund-raising ideas, which I think Mike would appreciate and I hope can come to fruition in the near future. In the meantime, if you knew or worked with Mike it would be great to hear your memories of him.
The post Mike Hibbert – A Celebration appeared first on Rittman Mead Consulting.
