Welcome back! Over the last few weeks, we ran through the Plan and Design phases of digitalML’s API Product Management Lifecycle (Go check them out if you haven’t! We’ll be right here when you return). Now we arrive at the third and shortest phase — Build. But don’t let the size fool you, because the output is ‘YUGE!
A quick recap: The digitalML API Product Lifecycle is a design-first lifecycle, meaning we don’t start coding until we’ve knocked out all of the details we need in the Plan and Design stage. In short, it kinda looks like this:
- Plan — Ideate, Plan Product, or See Progress
- Design — Create New or Extend Existing API
- Build — Generate Artifacts
- Run — Deploy Artifacts Using ignite or Runtime Manager
So what is this process of generating artifacts we speak of?
What does Generate Artifacts mean…
It means you are quite literally clicking a button. ignite automates your API Product’s code bundle and Swagger specification, so after reviewing in the Design stage, you hit submit, and immediately have your service contract coded in the language you need for integration.
But what it really means…
It means 10x faster Time to Market. We recently interviewed a client, a solutions architect at a leading retailer, who told us that a document used to take her 3-4 weeks to author. Now it takes her a matter of hours to complete the same action with ignite, complete with governance, version control, and impact analysis.
You have rockstar developers, no doubt about it. But the problem is, can you hire a whole fleet of rockstar developers?
Some companies manage to do so — and props to them. But how many services can your fleet push out a year? And how much of their time are they fixing mistakes, or getting caught up in mapping? Project-to-project, they might get 8 to 10 services out each — and that’s impressive — but if you’re at the enterprise level, you’ve got to get to thousands of microservices to win the race. (Yes, this is true. We work with lots of industries, and thousands is the target across the board.)
Developers of ignite love the platform because they’re able to meet their deadlines in a timely manner, sometimes even beforehand. Meaning more time for big-brain stuff (more on this below), and less time on perplexing monotony, like naming conventions.
Building fast means catching the big wave… and staying there
In his book, The Innovator’s Dilemma, global innovation expert Clayton M. Christensen explains that the pace of market demand simply does not promise to align with the progress offered by technology. Meaning, what customers want/need today might not look anything like what they want/need tomorrow. So we can’t always build off of what the customer wants, because they don’t even know what they want now; much less tomorrow. In other words — we have to be fortune tellers.
This is largely why so many companies have shifted their focus towards innovation to catch the proverbial wave of market demand. In order for your company to stay on that wave, you have to find the flexibility (it’s all in the knees) to plan for failure, and learn fast. This is why our enterprise customers are hedging small bets on commercializing disruptive technologies, and making rapid revisions. They are able to achieve this state through ignite’s incredible speed-to-market Build time, with decoupled middleware that keeps every Digital Product launched from becoming a hard ship to turn.
If the red line in the above chart is the first wave you’re trying to catch, what about the rest? Every industry is different, and the model changes as time goes on. Take the fashion retail industry, for example — no longer is competition based on the functionality wave, reliability, or even convenience. We’ve entered the wave of technologies that can offer competitive performance at the price level — hence the “fast fashion” commodity crisis. New products were built along the way to keep up within every phase, and in today’s world, those phases go by faster than ever. It’s no wonder half of the S&P 500 are expected to be replaced in the next decade. What an exciting time to be alive!
Consistency, Reuse, & Alignment
As we discussed in our last post, we at digitalML know building speed with control is possible, because we watch every one of our customers get there. Let’s assume you do need to turn the wheel — that much can be expected. Maybe you see a hurdle, or perhaps you know of a shortcut that might just get your product to that wave of demand a little quicker. It is imperative to be able to easily make performance changes, quickly, with control, without having to worry about shutting existing iterations down or losing governance along the way. When you’ve abstracted your resources into decoupled building blocks for reuse, a change can be made to one artifact without affecting everything behind it, like some stream of holiday lights on a series circuit.
Eliminating Human Error
Everything that comes out of ignite is aligned to the company’s architecture, development, and design standards. So your bottlenecks are avoided early on, providing valuable efficiencies of scale. The mappings you made in the Design stage are really going to come into play by the time you click “generate artifact” in the Build stage, because you’re not only generating the code, you’re also generating the metadata, aligned to your stakeholders system and taxonomy, behind every building block.
As we all know, mappings can present plenty of opportunities for human error in a traditional Build stage, no matter how brilliant your team is. Luckily, ignite captures the workflows early on. So you never have to so much as look at a single spreadsheet.
Domain-Based Information Model
ignite lets developers assemble products using core building blocks that are already aligned to data model and taxonomy; building blocks that talk the way the business talks. (Naming conventions = the greatest cuprit of those pesky bottlenecks!) Every artifact is mapped to stakeholders systems, so flow and lineage are clearly visible, and impact analysis is made in the design stage, when changes are cheaper.
As we covered in Design, ignite has the ability to generate various arifacts based on information captured in the Service Definition, Service Specification, and Service Contract. These generated artifacts, listed in the next section, are used in the Service Implementation process, often using runtime tools that generate code from these items. Much of the implementation work involves taking this code framework and extending it further to implement the Service Contract.
Code Templates. ignite facilitates code or other artifact generation by using a set of runtime-ready templates that operate on the Service Specification and use the information in it through variables resolved in the output artifacts. The purpose here is to decrease implementation time, reduce cost, and increase consistency via Specification-driven development. AKA giving your developers weeks back on every project.
Deep-Dive View of Generated Artifacts
In the Build stage, ignite automates several outputs, including, but not limited to:
- Swagger Specification — for a standard, language-agnostic interface to REST APIs
- OpenAPI — for a publically available API
- WSDL — XML format that describes your web service (SOAP)
- Custom Message Specification — for event specifications
- Generations — for C# (yes, even for C#!)
So now the question is…
What are your devs gonna do with all their free time?
We’ve started a list for you:
Things Developers Can Do With Their Free Time
- Business Logic — See: Plan stage.
- Implementation — Start work on the Service Contract.
- User Experience — Connecting to the front-end.
- Backend Connections — See: Design stage.
- Go Bowling —
That pretty much sums up the Build Stage. Check back soon to read about the final stage; Run. We have all kinds of updates regarding runtime in our newest release, out next month.