Welcome to this summary of the full Abstracted API and Service Lifecycle Build to Run stage. You can download the full whitepaper at the end of this article.
The lifecycle is broken down into 3 stages, and you can access the overview and whitepaper for each one here:
Key definitions and reasoning behind this series
The digitalML version of the lifecycle takes a design-first approach, and focuses on plan, design and build with integration into the run phase (and because the plan, design and build stages are working with an abstraction layer, this is suitable for any runtime environment). We do this because we believe this enables you to become an intelligent enterprise and gain competitive advantage.
Overview – what happens in the Build to Run stage?
This stage is where you generate all the artifacts for your chosen runtime environment. The real power is in automation of this stage (which we’ll discuss in more detail later) because it enables development at scale. In our experience, most large enterprises will need 400-2000 APIs in their catalog to reach full API maturity. In order to meet this huge requirement, manual coding just isn’t an option, and your development teams could be better using their expertise elsewhere in the business. By leveraging automation as part of this full abstracted lifecycle, you can expect an 80-90% reduction in time and cost to market for new digital offerings.
Once your design is complete (see design stage) and your output template is selected, you can simply press a button to auto-generate all your code artifacts (including security code, orchestration code, transformation code, test conditions), with the exception of business rules, and deploy to your SCM. This means that the only manual coding required is said business logic and any front-end applications that may be using your atifacts.
If you come across any problems with your new product while testing in the sandbox e.g. throttling levels, you can go back to your design, make the necessary changes and then auto-generate the updated code.
It is also important to generate control settings for any gateway/proxy you may use. If these settings are generated directly from the design, you ensure that your design and runtime implementations are never out of sync and further speeds development as you’re not having to manually generate all these settings.
Example Use Cases
*Note to reader: Throughout all the examples in this series we will be assuming that the
enterprise has built an abstraction layer of digitized business functions and are using a platform
like ignite to maintain and extend it.
Value of Integrated Automation
Automating the build to run stage best enables your enterprise to meet its requirement of APIs and services to gain a competitive edge over both incumbents and digital disruptors. Here’s why:
- Rapid reduction in time and cost to market – building is simply pressing a button
- Means that your developers are not spending hours/days/weeks writing manual code – they can be focusing on different business goals and putting their expertise to better use
- Baked-in proper governance – minimizes human error and means you can auto-enforce security policies and standards
- Everything you build is consistent, reusable and secure – your abstracted design can be reused again and again by different teams even if they require different runtime environments; they can simply select a different output template
Download the Full Whitepaper
Download the full whitepaper now to:
- Understand the critical capabilities your enterprise needs for success in build to run
- Benchmark where your enterprise is in maturity of this approach, and identify the next steps to competitive advantage
- Learn how the ignite platform supports the build to run stage