This is the second part of our series on How Enterprises Foster Innovation and Grow Developer Communities. In part 1, we looked at the innovation value chain when applied in an enterprise setting.
The enterprise may not seem like a natural place to foster innovation so a developer must ask herself, how can I move ideas forward within an enterprise context? (See the video below for more answers)
From the perspective of an enterprise your solutions always need:
- The solution must match the enterprise.
- The solution must match the partners.
- The solution must evolve along with the business’s maturity.
- The solution must encompass all relevant stakeholders.
- End-to-End Solution
- API Management integrated with the software development lifecycle.
- Runtime enforces policies determined by architecture and enterprise strategy.
- Runtime monitors usage.
European technical director for SOA Software Andy Jones calls it an emerging discipline in enterprises and the solution needs to evolve while that happens.
From the perspective of your Partners or API consumers, your solutions always need:
- Be responsive and fast to meet emerging technical trends, protocols and standards, like using a RESTful architecture and JSON as a payload format.
- Present different interfaces to your different partner types.
- Provide the right support structure and infrastructure.
- Use a layer to present your API via flexible layer, be it coding, messaging and data structures, the security layer or the transport protocol itself.
- Make it easy for them to discover what you have to offer.
- Make it easy for them to get help.
- Allow and foster a culture of collaboration.
- End-to-end Solution
- How do your partners understand this: Onboarding? App approval? Promotion of the API?
For both sides, measuring matters
Allow both sides to access the same measurements, it helps you both have a transparent view and it helps you both understand where the other is coming from. Of course, openness is essential in any community but perhaps particularly so in the developer community.
What to Deploy: Gateways vs. Proxies
Jones says that by deploying a proxy, you keep everything lightweight so you can remain focused on edge security. If you follow the route of gateway layer deployment, you allow raw services to be manipulated before they are presented to the developer community.
Jones’ team favors the gateway layer solution, but admits that it “partly depends on the maturity of the organization from an integration point of view.” He goes on to explain that “If the organization had comprehensive SOA in place that it could manipulate quickly and was willing to risk capacity changes on a fairly short notice, then the proxy kind of does the job, it adds that edge security,” which he refers to as the major differentiator for external consumption. If you don’t have this edge security in place already, “then the gateway helps to fill that architectural gap.”
How Should Organizations Prioritize Their Systems
1. Systems of Record: A mild pace. These store the fundamentals and don’t have a need to change, at least not very often.
2. Systems of Differentiation: Start to accelerate. These are characterized by the market itself and need to change at least as fast as market demands do.
3. Systems of Innovation: Put the pedal to the medal, it’s time to go full-speed ahead and try to leave your competitors in the dust.
As you increase the speed of changing systems, your governance controls must keep up the pace. “We see the role of the gateway applying at those upper levels where we can make policy changes really quickly,” including:
- where you can back out of API decisions
- where we can reset API decisions
- refactoring some of the API design decisions around security policies
- refactoring around usage policies
- refactoring around scopes of the APIs
- introducing operations
- withdrawing operations
How do you allow for enterprise-level restrained flexibility? Comment below and tell us.
This is part of our series on How Enterprises Foster Innovation and Grow Developer Communities. In part 3, we will look at how to attract external developers to your API.