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.
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.
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.
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.
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?
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.
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.