If you are looking at a vendor product for your company, there are good reasons that you are doing so. Your organization has a need that their tool can possibly fill. But, how often do you see marketing hype from software vendors that looks too good to believe? In so many words: “our product can do everything you need.” No, be wary of anyone who says they can do everything. Their products obviously have value, but there is a positioning in place to lock you into their products for a long time. A lot of the time, the prime focus is around where your business logic is supported, and how dependent you are on a given tool. Embed a large amount of your business rules in the vendor product, and the ability to shift your architecture and add or replace products become very, very difficult.
Let’s face it, tools and platforms are evolving at an amazing rate, and we have to replace or add or move to new tools/services as a matter of fact. As an architect, I have to balance capabilities vs flexibility vs speed vs cost for the near term and long term. Leverage products where they are strongest and balance your tool usage with your strategic direction. Have separation from tools when possible/allow for a quicker replacement of tools (swap out). Black-box capabilities and functionality in your enterprise and application architectures whenever possible. This minimizes the touch points of where modifications need to take place. The more black-boxed your architecture is, the lower the cost when you eventually have to do a shift.
Good examples are ETL and reporting tools. How many of us have SSIS in their architecture for data movement? And have to uplift to the cloud and replace it with another data movement tool(s)? How about a high-end reporting tool that has its own ETL/scripting language that might be easy to use at first. Good for quick turnaround, but very inflexible if you need that information available for consumption in the rest of your architecture. Limited use. That’s fine, especially for one-off data/datasets you need to leverage. But once you start putting everything in the vendor tool—especially with a vendor proprietary scripting language—you’re stuck. It will take significant effort and money to move or implement your business logic elsewhere. That is the trap.
For ETL tools, leverage the data movement and workflow capabilities, and limit the business rule embedding. Black-box the business rules and processing so you can readily update or swap out for something else. Even with tried and true SQL Server Integration Services (SSIS), we are ripping out the business logic from the tool (placing it in reusable modules/stored procs) and focusing on leveraging the data movement and workflow capabilities. For reporting, leverage the pure reporting capabilities. Use the added functionality, where needed, but govern and limit functionality that is better suited and supported elsewhere. Reporting tool scripting/ETL capabilities is a prime example. Have the majority of your business rules closer to the backend data to mainstream and generically support any type of reporting and reporting products. Strategic tools—such as data/database platforms—are harder to move, but are still in-play as multiple data platform usage is more the norm with the advent of the cloud.
Other factors in-play
With licensing of vendor tools, the more locked-in you get, the more you are at the mercy of that expenditure for a long time. Another consideration is that when we have tools, we need skillsets in our organization (or contractors) to support. More tools in the market makes it difficult to find the limited resources to support the investment. Another trend is in organizations getting their own tools outside of IT due to the speed of implementation, or control, they have over dealing with the backlog with IT. Let’s face it. IT is often is in a “keep the lights on” mode due to funding constraints. Have IT partner with business and encourage multiple organizations to go in a common direction with their tools selection(s) for a lower Total Cost of Ownership. Also, to have the ability to push critical business logic/common definitions, and shared data assets, from the business back into a shared environment available to the rest of the enterprise. This ties into an overall data-governance approach. The more common a definition or the processing involved, the less you want it buried in a vendor product.
Remember, the speed of product evolution is staggering. If you have to replace a tool, make it as plug-and-play as possible in your architecture so you can shift without trying to justify why you have to request the expenditure to reengineer your architecture because you or your predecessor lock yourself into a single product and direction. Do not put all your eggs in one basket, and give your business a chance to evolve—as you know it is going to happen.
So, how are you set up? If you still have any questions around the value of any vendor tools, please don’t hesitate to reach out to us. We’d love to help you get started.
Business Intelligence Architect