Who Should Read This?
Delivering value-driven software means harnessing several motivated disciplines across an organization. Subscribing to a product mindset isn’t limited to just production teams. This means technical Solution & Delivery (S&D) groups must establish healthy relationships with Product Management (PdM) teams to create a winning approach. Administrative disciplines such as Procurement Specialists (PS) can also help accelerate the change needed for digital transformation in 2020 & beyond.
We invite each of these groups to join the conversation.
- Product Management
- Engineering Leadership
- Procurement Teams
Introduction
The enterprise solution marketplace is vast and overwhelming. For core competencies like digital commerce, customer data management & catalog manipulation there are thousands of solution providers and custom development approaches. And now, for newer supporting practices like machine learning, IoT & data lakes it’s even more difficult for leadership to make informed, objective decisions about what to use to meet customer demands. How you position your solution procurement processes will mean the difference between designing & building custom software or buying an off-the-shelf application.
While the financials are certainly critical, early math may lean towards buy but the market may be demanding new capabilities altogether. It’s also possible to end up deploying your best talent against a bespoke approach that meets market demands but is simply unsustainable. A balance must be struck. Positioning for learning as well as change is critical.
While none of us can read the future, we can release tools that are - by design - adaptable to both internal change and market fluctuations.
In this exploration, we’ll rally around a mindset rather than a hardened set of rules for thinking about procuring enterprise-grade software.
The Problem With Versus
Build versus buy is the former generation's battle. Buying while building is the new reality.
In this new reality, there are certainly conventional considerations that we'll discuss but there is also a level of nuanced thinking that could really take your proposed initiatives to the next level. The debate around build versus buy for enterprise software has shifted. The advents of domain-driven design, serverless infrastructure, the popularity of microservices and API gateways means businesses of all sizes are taking more of an integration mindset to the way systems deliver value.
This opens the door for custom feature sets supported by prepackaged platforms that can be continually configured to meet specific business needs.
While the platform feature set handles core dashboard tooling, database concerns, authentication and auto-scaling (to name a few) your organization is freed up to release independently deployable features that are refined representations of market demand. Building should not be in competition with buying. They should be working in tandem.
3 Types of Organizations
Any size organization with any amount of resources will more than likely have the same Build Vs. Buy dilemma so we’ll explore each organization type through the lens of all things being held equal.
1. Build Absolutely Everything
These are savvy, technical leaders who have had sometimes huge success in the past in building custom software from scratch. They understand the nuances of custom software and how to build something new and exciting but also how to release it into the wild. They understand user feedback loops and can justify the costs involved with iterating and growing a successful product. This organization has engineers who are specialists at either a programming language or data architecture and can even navigate DevOps at scale. They deserve the opportunity to build the best possible solutions for their organizations and understand themselves to be the best qualified to do so.
There's also a culture that may think that there are some cost-saving opportunities when building on their own. Their S&D teams have witnessed packaged tools offer less value than a custom approach, while often incurring higher costs. They want to avoid multi-year contracts that can sometimes span leadership tenures which leave large initiatives incomplete & unexplained.
2. Buy Off The Shelf
There is also a school of thought held by many business professionals - IT organizations included - that economies of scale are more easily reached with off-the-shelf offerings. Beginning a new business initiative shouldn't have to mean starting over with new lines of code when there might be several industry leaders tackling the same problems at scale. Working with existing solutions and account teams that have seen "every variation" of your problem is compelling and frankly practical. This organization has decided re-inventing the wheel is often too costly in terms of economics and attention; deciding instead to resolve their business problems with a proven SaaS offering.Their thinking is even if they could build something valuable it couldn't possibly be as powerful as what hundreds of companies are already delivering. Why take a chance on delaying your release when you could sign a contract with a partner and start transacting next week? Why dive into the software development business when your shareholders are expecting retail sales?
3. Rent, Configure and Extend
Neither of the previous philosophies are wrong. In fact, both schools of thought probably exist in your organization.Our third organization type plays both sides against the middle. They have leaders that have seen success with both approaches who find opportunities in blending the best of both worlds.They know they must be careful to avoid exposure to the pitfalls of both like long contract obligations or exorbitant support costs. The build & buy philosophies are constantly pulling away from one another so the art of keeping them in harmony must becomes the focus.The architects & teams with platform subject matter expertise are hard at work keeping up with quarterly updates and keeping the rest of the organization informed of their impact. The bespoke engineers are busy working with internal product teams on short & long term business goals and how they translate into releases.
5 Critical Considerations
You will no doubt undergo a thorough request for information process followed by several rigorous request for proposal rounds. Economics and support SLAs will be scored and rescored based on your Procurement & Enterprise Architecture policies. However, before you endure what normally would take months because of indecision have you considered the following?
- Gap Analysis
When - not if - a gap analysis is conducted proper stakeholders need to be brought to the table. This exploration is more requirements gathering. This is a thorough examination of existing tools.
Have you exhausted every current vendor contract for savings opportunities? Have you held existing partners’ feet to the fire for their own SLAs and demanded credits where there may have been failings? Are you using every possible feature you’ve already sunk hundreds of thousands of dollars into? If your answer to either of these questions is “no” you may have a fiduciary mandate as a steward of your organization’s budgets to do so.
After which you can responsibly say you've assessed your current state and begin measuring your “as-is” against your newly stated business goals. Subject matter expertise is required from all relevant disciplines. The conversation should include driving towards a pure and objective interpretation of where you are today.
For any initiative, whether you're building or buying, if your organization has not performed and published a gap analysis you are simply unprepared to take on the decision making process. These vetted artifacts are critical ingredients for any successful RFI or RFP. - Security & Performance
Consider the law of averages when thinking about building your own security systems. Can you build a system so resilient that you can identify & neutralize thousands of attacks before any single vulnerability is exposed.When working with a SaaS provider, they’re typically dealing with millions of varying attacks more often than any single entity could even collect data on. The investment in both security & performance that they have made is exponential. Try to engage potential partners who are eager to tell stories of how they’ve brought order to chaos and open to providing references.
SaaS platforms may have seen many threats and many performance configurations from several industries thus making their provisions holistic. Leveraging their portfolio of learnings is certainly a good idea. It's not a negative shot at your organization's security team to stand on the shoulders of a SaaS models learnings. Deploying your security team, against already solved problems may not be prudent.But if you find yourself with such a unique use case that no partner can provide any interesting outlook you may have to look inward. At this point, you’ll do well to use partners for non-essential functions and build custom counter-measures yourself. - Ongoing Support
Whether you build, buy or both ongoing expenses & support are inevitable. Your customers, whether internal or external, B2B or B2C will expect a healthy feedback loop, attention paid to their interests, so on and so forth. The world of support cares not that you bought a service or configured your own. They deserve the highest levels of service from your brand.
Your core customers will drive the top of the bell curve of concerns but you'll still want to keep a priority focused on service levels from the field of use. As feedback flows into the organization it needs to be fielded by some team. That team is either the first line of defense support group internally or the first line of defense support group externally.
Depending on your implementation approach your service strategy may not change considering it should be attached to business goals. However, the level of your own resources' involvement will determine your service design. Managing multiple partnerships will take quite of a bit of attention being paid to service levels. Managing your internal stakeholder's expectations against what's contracted requires constant awareness - especially for newly released software. For the initial quarter(s) after a release, you will want to inform your organization early and often when any SLA deviations are anticipated.
In response, your stakeholders will rightfully request a change management & release plan. The considerations should be at the forefront in early conversations around build vs buy decisions. Their answers will help shape how to proceed; not just with a lens of releasing but with the full scope of post-release planning. - Total Cost of Ownership
There are countless TCO wizards and calculators to assist with arriving at total cost of ownership for your new solution. However, we’ve noticed a trend of those “TCO Calculators” over-indexing towards initial costs rather than the entire spend spectrum. To their defense, the expectation is that upfront costs are all you’re initially concerned with. Fine for early conversations but presenting to with steering committees involves more than the tip of the iceberg. Just as an iceberg’s momentum and mass is primarily set under the surface, that same is going to be true for your new program. During your capital expenditures, you’ll incur several known costs however, as you move close to deployment and post-release maintenance you’ll often be confronted with new considerations. These are considerations dealing with compliance auditing, responding to market feedback, retaining subject might include subject matter experts for at least a couple quarters. These are cost multipliers that must be considered for both initial costs as well as ongoing expenses.
- Product Mindset
Forrester* calls product management the cog that enables organization synchronization. Companies have found themselves dependent on technology and customer’s believing in their brands. Balancing them both has routinely gotten lost in priority lists. But a new line of thinking is striking the necessary balance between solution delivery and customer feedback.Product Management can seamlessly design strategy, evangelize a vision, conduct road-mapping exercises and maintain a living backlog. All of which are more than necessary when making procurement decisions. Is there a product mindset in place to drive conversations with C-Suite? Is there an advocate in your organization whose allegiance is the complete Customer Experience and not a single line of business? Is there anyone rallying concision around a strategic set of goals? Is consumer feedback used to drive growth & change?A product mindset embodies all of these qualities and without one your new application may struggle to get the proper care & feeding. Whether it comes in the form of a mature practice area or an internally shared philosophy it's proving effective across Fortune 500 companies, startups and every category in between.
Designing A Product Culture
Culture Shift
The rent and configure culture requires a bit of a culture shift. You're still going to have to tackle clickwrap contracts. You'll still have to hire a capable development team. You'll still have to support your own releases against your product roadmap. You'll still have to have a product roadmap. You'll still have to keep a close eye on analytics and quality. But now you're empowered with a dashboard console and a support team that can assist you along the way. software that requires certifications. Just to manage can sometimes feel overwhelming. But the advantages of a strong Enterprise Architecture demands subject matter expertise in the applications that were purchased that meet certain spend criteria. If you've invested $4 million in a product, you should expect that those certifications should be in-house, and there should be. work done to redundancy in that knowledge to fully certified experts may be eliminated. Helps you ask the right questions when engaging with your
Maybe the culture shift is moving away. Versus buy against each other. But maybe the culture change is accepting about understanding the values of both and building teams around that reality. Maybe the culture shift moves more towards delivery, then develop and support.
Dashboards & Analytics
Analytics is important in finding out the health vitality of the tool that you have in production, with real-time feedback, is critical. It's the only way you can compete. It's the only way you can stay one or two steps ahead of your competitors. That said, you'll need to develop dashboarding features. So on top of the data source on top of the integrations. On top of the compute power on top of the API's that you'll need to build. You'll also want to build an interface that will give you real-time information about user usage behavior and anomalies. And also performance. You'll also want to integrate. At some point, technology that will show you gaps that sometimes Out-of-the-box analytics might not demonstrate. Understanding this means that you and the platforms. Need to ensure the data is exposed in such a way that it can be consumed by plugins or other models that can help. Use your data in new and exciting ways.
dashboards need to be available via mobile web. They need to be responsive, the interface needs to be clean and speak the language of the stakeholders who set out to begin the initiatives in the first place. If you're prepared to build in these provisions, then building may be the way to go. But if these are daunting, or somehow overwhelming. Most platforms, again, are in the upper right quadrant, because they've solved these problems before they brought them to resolve.
Bias towards learning & evolution
With the product mindset. You want to instill a bias towards learning, and evolution in the beginning. So every requirement. That's gathered is not about current pain, but a future-leaning into the holistic universe of meeting customer demands will make for a more healthy project. And make way for an easier adoption inside of the organization's operations with a product mindset bias towards growth. Reduce internal pushback offer an olive branch to internal organizations that otherwise might not lean your way.
Availability of development, maintenance & support teams
As an extension of the timeline. Let's make sure the available availability of development resources is on par with what's needed for your release that after it's released that you have a proper maintenance and support plant that once you're in the wild, that you have ongoing expenses Allocated. And don't choke, your stakeholders' feature requirements. Because of unplanned support. Spend. You want to design an availability and support approach that accommodates the possibilities of the market's response to your tool, and not just the two or three headcount availability. Support requires leadership, as well as development resources and product.
Separation of concerns
When building software. The teams involved. And every line of code written, every library introduced. Every framework package that's installed must follow a theme of separation of concerns. Security should always be able to be audited at any different time unit testing and deployment should be in the hands of the development to quality, while everyone's responsibility. should be checked every opportunity, continuous improvement is key. But separations of concern are critical. Software must be modularized team attrition is important so documentation is important. And we would argue for microservices and domain-driven design to help. That's a pattern that can help solve a number of these concerns.
True Requirements
Before any software development project starts or RFP for finding a platform. Problem case needs to be written. I have passed the system needs to be crafted and requirements. Ready. Requirements aren't necessarily feature-focused. They're more function focused on what I would like to achieve what the customer should be able to achieve what they intended business outcomes are. What is the cost of this software, starting it today, and finishing it six months from now, what does that cost, our business, in terms of how much that dollar could have been worth allocated towards something else. requirements gathering becomes much more intensive. If you are building custom. They can be more exact, when, because of the freedom, afforded by custom development, Almost lends itself towards more particular requirements. However, these requirements still have to be conceived of approved and published building software. Sometimes it isn't worth the trouble to gather requirements. Acquiring software. However, sometimes means that business goals are all you need to surface to the partner. Sometimes the platform partner understands requirements, better than the stakeholders. While you may know your business. Better Than Anyone Else requirements for meeting business goals are something that they've built entire businesses around addressing.
Do you want to move at the speed of the platform or the market?
Do you want to move at the speed of the platform, or the market. As the market responds. Most platforms will also be listening, they'll even offer thought leadership around trends that they're seeing trends that you may not actually be privy to. But that doesn't mean that move to accommodate any gaps that their platform has, in time for you to respond to the market, those considerations have to be tested conceived of developed tested released deploy, and then ensure that no break fixes ended up into your software. You'll have to do the research and planning and sometimes frustrating work of making sure the tools are moving at the speed of your company's growth. Otherwise, You'll only move at the speed of their platform.
Timelining & Roadmapping
Timelines are not just about the start date. Project milestones in end dates are proposed in dates. They're not even about critical path items, or blockers along the way. acceptance criteria pattern. A true timeline includes your market fluctuations. Your customer promotions shareholder, and stakeholder churn in demand. Participant turnover. This means employees and developers, typically, roll-off projects because of contract resources timelines include the entire universe of operations. Not just the project itself. How quickly can you achieve zero index against projects. And is that going to happen before your first market fluctuation. If it's not going to happen until afterwards possible the funding, get frozen. It's possible that the board would want to reroute finances justifiably so your timeline needs to involve. Not just your release. But the time it takes to onboard your organization and its culture to the idea of this new tool, being in market. This includes training awareness. Launch documentation proper positioning amongst the rest of the Enterprise Architecture tools.
Every dime spent
Every time spent on building supporting software is made more expensive. When that team isn't supporting something else, there's an opportunity cost for your development teams working on this software and not solving the problems of your business. Because remember, solving the problems of your business should always be the most important, and not implementing software.
#1 resources
Remember, you want to deploy your number one resources to solving business problems that no one else could not be solving software problems that you can't get a partner to help you figure out. Position yourself, such that your most talented resources are solving business problems, and all other resources are in the audience have that thought leadership and contributing as well. Essentially, not hiding your best resources in a project. Dressing them forward to meet the demands of your business and making sure those lessons learned, are made public.
What business do you want to be in?
What business do you want to be. Do you want to be in the business of servicing customers and understanding customer needs. Or do you want to be in the software development business. If designing software is what you report to Wall Street. Then I agree with the ladder. But if revenues gained by servicing customers is what your shareholders, hold dear. Then control shouldn't be your aim should be holistically servicing customers. And sometimes, answering that question. requires the purchase of industry-leading tools. Rather than building them yourself. But then, coming behind that acquisition and customizing accordingly. If you can't offer customizations that your brand requires, then it's not a good acquisition tools can often service industry, very well, but it often takes customizations to deliver on brand promises. I think that's going to be kicked.
Everything at scale
Yes, you can spin up a new instance, yes, you can spin up and provision, or redundancy strategy. Yes, you can spin up APIs. The question is can you do it at scale. Can you do it at the speed of your business? Can you figure all of those things out in the same runway, that it would take for someone else who's already got that figured out. The question is can you do it at scale. And it's not a matter of Ken. It's a matter of planning for it. In the beginning, planning for as your revenue and customer variations change at the software you build can accommodate that growth at the speed of your shareholder's expectations at the speed that you can support it at the speed of the security standards that will be required for growing in arrive. If the answer to all of those questions are Yes, I'd actually encourage you to build the software. But if you've got to know or maybe in any of those pieces. Except that, in 95% of cases, there's already some software built that can accommodate.
The Bottom Line
Key Takeaways
The rent and configure route requires a bit of a culture shift. You're still going to have to tackle clickwrap contracts. You'll still have to hire a capable development team. You'll still have to support your own releases against your product roadmap. You'll still have to have a product roadmap. You'll still have to keep a close eye on analytics and quality. But know that you're now empowered with a dashboard, robust consoles and support team that can assist you along the way.
Software that requires certifications can often feel overwhelming but subject matter expertise can make a critical difference. Overall, the advantages of a strong foundation in your Enterprise Architecture outweighs the hurdles of specialized training. If you've invested 6 or 7 figures into a product, you should plan for in-house subject matter expertise.
You may not use these exact points in your RFP or procurement process but we want to help you build a framework to ask the best questions in your organization.
