Story

There are always multiple approaches to solving problems. In the IT landscape, this could be in the magnitude of 50 different potential approaches to solve a problem, especially when considering the number of solution platforms, programming languages, and vendors with similar or competitive offerings in the marketplace. Rationalizing the “best fit solution” to solving a problem can be challenging, if not downright cumbersome, when there are so many choices.  Factoring in human factors such as strong opinions, level of comfort, curiosity, personal favoritism or biases, can make choosing a solution approach even more challenging. Ultimately, choosing a solution approach should be based on what is best for your organization, when considering cost and overall benefit or value derived from the selected approach.

For microservices the goal is to build or re-use existing integration assets as an enabler for solutions across the entire enterprise.

To accomplish this, your organization should follow approaches that invest in architecture and supporting frameworks that can be re-used across microservices Use Cases and solutions. Such frameworks require an upfront investment to reap the benefits downstream. As illustrated in the graphic, creating the microservices architecture, which includes foundational architecture and enabling frameworks, allows for your company to have the blueprints for building new functionality and leveraging re-usable assets, ultimately making the solutions operational and deriving value for the long haul.

Microservices Architecture Maturity Impacts on IT Costs

At times, there may be a simpler, less complex implementation approach than the “standard microservices” approach, which seem faster or even less costly. However, alternatives from the standard should be justified to determine if they present long-term lower ownership costs. In other words, what may seem simpler on the surface, but may be costlier over long haul. This especially holds true when measuring factors such as operations and sustainment, change management, future solution modernization, scalability, flexibility, and overall governance. The most common issue is building a point-to-point or 1-off solution that is costlier over the long haul to manage, maintain, and support—hence, a higher Total Cost of Ownership.

Microservices Re-usability lowers Total Cost of Ownership

To maintain low Total Cost of Ownership through microservices, the following principles shall apply:

Leverage the standard microservices platforms, tools, and technologies, selected by organization and justify any exceptions to the standard for consideration.

Leverage the architecture patterns and approaches established.

Leverage the enabling “microservices Frameworks” established.

Bring collaboration and feedback on the standards to the Enterprise Services microservices Governance team as early as possible so it is considered in the design and rationalization. If the scope is broader than a single team solution, then the solution team shall consult with the governance team and other groups and teams to establish the proper solution approach.

Leveraging standardized “Cloud based platforms” to keep costs low. When considering cloud platforms, the preference is to leverage Platform as a Service (PaaS) as the first criteria (See Section on Tenet: Microservices Architecture). Second criterion is to leverage “container-based solutions” so the microservice can be created, deployed, and managed independently from other microservices, Operating Systems, or Virtual Machines. This will help keep the TCO low.

Story

When evaluating API Management and Portal platforms, there are a number of capabilities to consider. Below I have provided a list of such capabilities for API Management and Portals that you should score the platforms (and vendors) on. This is a high-level list, and I have a more detailed list if interested in reviewing for evaluation purposes. Also, this article is focused just on API Management and Portal capabilities. I will have published another articles focused on more capabilities to evaluate platforms (and vendors) on, such as API Gateway at: https://www.linkedin.com/pulse/api-gateway-vendor-analysis-best-practices-jordan-braunstein/

Please reach out to me if you would like to discuss or review these capabilities in more detail with your team at: Jordan.Braunstein@visualintegrator.com . I have personally evaluated and score-carded the following API Gateway Platforms (in no particular order):

• MuleSoft
• WSO2
• Kong
• AWS API Gateway
• Azure API Gateway
• Gravitee
• Boomi
• Redhat 3Scale
• CA Layer 7
• Apigee

1. Ability to Onboard Providers and Consumers
2. API Marketplace, Catalog, or Exchange features (beyond API Portals)
3. Shared Repository Integration if using an external repository such as Artifactory or Nuget
4. Version Control
5. CI/CD Integration
6. Manage Consumer Groupings
7. Testing Tool Integration
8. Debugging Features
9. Mocks and Data Virtualization
10. API Provider and Consumer Analysis
11. API Contract Designer Tools
12. Policy Re-use across Consumers
13. API Monetization Features
14. Generate Documentation
15. Integration to ticketing systems
16. Features for Mobile App Consumers