A friend of mine founded a software company a few years earlier than we did. His definition of “making it” was when he got to fly in the big planes – visit customers in larger organizations in the major centres….with airports people actually want to go to.
On his definition, WhereScape has definitely “made it”. Over the last couple of years we have seen more and more leading organizations engaging with the concept of building data warehouses faster, and subsequently utilizing WhereScape RED.
As the concept becomes more prevalent we find we are no longer just selling to strong willed individuals who want to make a difference, but with full on buying committees. And data warehouse architects are on those committees.
In our mid-market customers the data warehouse architect can be a part time role, taken on by one of the team alongside their other duties. In the larger organizations the data warehouse architect is a key person or are key people. In all cases they are responsible for the long term viability of the data warehouse. They need to ensure that short term decisions don’t have unintended long term consequences, they need to be aware of technical debt, and they can be called upon to be the conscience of the data warehouse team: to say no, or watch out, when everyone else is saying go.
There is a very real problem, however, with the data warehouse architects, and it stems from the fact that they are often really smart people. They go to the conferences and listen to the analysts and they keep up to date with the new topics and advances. Somewhere in their job description it says “make sure you give vendors a hard time”. I am sure some of them are paid on the number of times they can trip a vendor up, with extra bonuses for cruel and unusual questions.
Given their reputation, our well-worn path was to go around them; who wants to be given a hard time every time you go to meeting? It turns out that this wasn’t too hard. We are often endorsed by strong willed business users who are adept at ushering software they want through the purchasing process. And the architects were more concerned with bigger picture questions than worrying about getting value from what was already in place.
Then a funny thing happened. We started to be invited to meetings by architects. They wanted to talk to us. They wanted to engage with us so they could offer more to their constituents. Not all of them, but often the ones from the larger companies (near the big airports).
We would like to put this down to our superb marketing, wit and charm. A more likely reason is that the rules have changed for the data warehouse architect. They have widened the interpretation of architecture to include time to value. We certainly owe a hat tip to the agile data warehouse and agile business intelligence movement here - they have been leading the call for change.
I recently met the chief data warehouse architect for a global financial institution. His story was typical of what we are seeing now. Their new data warehouse strategy included a section on being more responsive and delivering faster to the business – and he wanted to know how we could enable this.
This is a fundamental change, and a great sign for our industry. Our architectural discussions were previously based around compliance and future strategy. Now the architects are talking to us about value. And the architects are the right people to be having this discussion. Considering value up front, giving it a seat at the table, means it can be built into processes, and can influence other decisions. This can only be positive for business intelligence, and specifically the data warehouse.