Services automate your business processes. It’s true that all software is automation but your core business processes are different. These processes are the heartbeat of your company. Having them available as services allow you to automate your business workflow in a variety of ways. A nightly job may update shipment data. A warehouse app may adjust inventory. A mobile app can be used in the field to enter data. With the processes as services, every contributing subsystem (mac, pc, windows, script, job, 3rd party integration, mobile, web, etc) can use your system in a consistent way.
All too often teams jump straight to building applications without thinking through their service strategy. I’ve worked for many companies that knew they wanted an application or a web site. Only a few ever talked about a strategy for the design and maintenance of services.
This is understandable. Many projects start as experiments. Startups claim they want the freedom to innovate; that they can’t be bogged down with infrastructure. Established companies often just build on what they already have, extending an already tangled monolith derived via functional decomposition. The transition from a monolith to services has many risks that are very hard to understand if you only have experience with monoliths.
And regardless of what you want, there are constant schedule pressures. The refrains such as, “We don’t have time for that,” or “well do that later (once we prove our idea)” are common.
With so many headwinds against a Service-Oriented Architecture (SOA) many teams never seriously answer the question, “Do we want a SOA?”It’s not an easy question to answer. Service-Oriented Architectures are easy to get wrong. Developers are usually experienced with monolithic code, very few have SOA experience.
Teams often assume that the transition from a monolith to services is the act of putting existing functionality into services. But this assumption often leads to problems. Existing monoliths may not have been designed with clear internal service boundaries. Most monoliths are designed for integration with the UI/UX, but what works best for a SOA is to automate the business workflow. The monolith probably has the business workflow in there somewhere, but it’s unlikely to have clear boundaries. Some engineering into workflow oriented services is probably needed.
This is one of the first places that a software architect may run into trouble. The business workflow will need to be analyzed and decomposed into a set of services that can be maintained and evolve. It’s unlikely that the functions in the monolith will match what makes sense for external services focused on the business workflow. This analysis can often be very difficult the team that built the monolith. They have a view of how it functions and it can be hard to separate that view from a view that makes a smart collection of services.
Automating the business workflow separately from the design of applications will actually speed up development and increase innovation but the purpose here is not to convince the reader of these benefits. Quality engineering practices have always had push-back as their industries have evolved. Why should software be any different. It’s often more effective to forge ahead, rather than to try and convert the status quo. Prove by doing, not by convincing.
This series of articles is an attempt to support those that want to move their software projects forward faster with higher quality through sustainable development techniques and practices with a focus on services. It’s not meant to be a one-size-fits-all discussion. The assumption is that you’re working on business systems; that you have a notion that your team can benefit from a SOA.
Henry Ford said, “If I had asked people what they wanted, they would have said faster horses.” He didn’t bother with horses, instead he refined the American assembly line which changed all of manufacturing, not just transportation. We want to create a software assembly line from robust, modularized, services that automate the business workflow.
The topics in this series aren’t strictly for service-oriented architectures but that will be our focus. The techniques apply even if you’re building a monolith and want the internal components to be well thought out and modularized. They’ll also serve you well if you’re building an entire product line or want to build very rich client apps.
If you’re thinking about converting a monolith to a collection of microservices then this series should help you create a road-map and show how to design the system services to live outside the monolith. One of the reasons so many teams find microservices so challenging is that microservices are really just services. The service-oriented architecture design techniques are really microserice design techniques. We’re going to discuss those.
Topics:
- what is core-logic (includes features vs system)
- what makes software reusable, resilient, and robust
- components, services, SOA, and microservices
— — — — — — — — — — — — END — — — — — — — — — — — — —
There is a tenet of good design that says, “Don’t build features. Features come from the integration of services.” This simple tenet is hard for many to understand because all too often teams jump straight to building applications without thinking through their services strategy.
“Don’t build features. Features come from the integration of services.”
What this means is that we want services upon which we can build any desired functionality. If you focus on the functionality first, you’ll end up building a series of one-off solutions. Many code-bases end up being a collection of one-off solutions. While there is no single definition for “feature” during code reviews you often hear the comment, “oh yeah, that code is no longer being used because we killed that feature.” [“When?” “Oh, that was before you got here.” yikes.]
Lets try an alternative version of our tenet.
“Build one-off code only when necessary, near the user interface. Make the bulk of your core-logic useful for integration into the majority of your use-cases.”
That’s much easier to understand. Near the UI or API boundary there may be some one-off compromises but the bulk of our system should be the core-logic that serves as many of our use-cases as possible by allowing our clients to integrate with the core-logic.
“Integrate with” means that we are using, not customizing the core-logic. This is important because it means our core-logic will need to be written for reuse. Designing for reuse is a bit counter-intuitive. It’s not easy to get right and it’s extremely easy to get wrong. It’s also a requirement for our core-logic. If we don’t design for reuse we won’t be able to service the majority of our use cases without custom, one-off, logic.
