Secure Edge Architecture



A Safer, Saner Way to Manage Ballooning Network Connections, Protect Your Enterprise and Keep Pace with Partner/Consumer Demands.

Takeaways:
• Round-the-clock implementation demands produce a host of disconnected “one-off” projects that poke holes in the firewall and expose your company to threats.
• Proactively designing your network edge and following best practices can secure your edge while speeding customer onboarding and putting more opportunity within reach.

Staying Abreast of Connection-Crazy Enterprises

CIOs are being asked to fulfill a growing number of enterprise connection requests that expose the data, services and APIs of your enterprise — and do it in a way that maintains security and integrity of the enterprise. If you are one of these CIOs, this can be nearly impossible with resources you’ve been given.

The rise of SaaS and cloud-based solutions places more enterprise data outside of your purview. Customers and partners want faster onboarding, more visibility into your services and more mobile access. Social media usage creates additional burdens and liabilities all its own.

The edge of your enterprise is constantly expanding and getting blurred as direct connections — largely managed file transfers, direct P2P interfaces and service/API calls — with trading partners, distributors, and customers multiply. “Where is the edge of my enterprise?” is not an uncommon question to be asking oneself in the fretful wee hours.

secureedge1

The “One-Off Trap”

In response to this burgeoning demand for greater connectivity, many IT departments — feeling like they’re on the hamster wheel of internal and external requests — fall into single-project mode, treating each connection differently. Separate projects are siloed with no view of their impact on each other, like-minded connections or the enterprise environment as a whole. This is understandable — they’re under pressure to make things happen quickly.

Seemingly innocuous one-off connections (such as a sales app connecting to a CRM system) made by individual developers may repeatedly poke holes in the firewall, creating a risk that others may not even be aware of and potentially incurring a steep bill down the road.

We start creating a “Tower of Babel” — disconnected, unconsolidated point-to-point connections that all need to be individually rebuilt if, say, a large core system to SaaS migration takes place. We have created a wide variety of different solutions to the same problem that increase cost, incur technical debt, and even more importantly, lead to a rigid enterprise that cannot move quickly in response to new opportunities.
Your project teams are not dedicated to integration and are not thinking from the enterprise perspective about risk management. As the CIO, you must. (This is why Deloitte’s Tech Trends 2015 suggests that “CIO” can really stand for “Chief Integration Officer.”)
In many cases, companies don’t even have an inventory of all their connections to the outside world. This is potentially a sign of disaster.

A Methodical Approach to Securing Your Enterprise Edge

A better approach, then, is to begin with the end in mind so that individual projects start aligning with a conscious approach to the enterprise edge. This effort falls into two major phases:

1. Make an explicit decision to design the enterprise edge as a whole, even if it is implemented project by project.
This will mean establishing the necessary governance to do this and includes implementing an “edge gateway” (or “connections gateway) that can serve as a focal point for making and managing all connections to the outside world.

2. You need to design the gateway itself. Here are several key principles to keep in mind as you make your plan:

a) Deal with edge-related issues at the edge gateway whenever possible.
This is the design equivalent of putting the socks in the sock drawer rather than spreading them all over the place. For example, don’t proliferate the specifics of Trading Partner (TP) interfaces (connections), info, and interactions across the internal enterprise. Rather, define and manage detail about the TPs in the edge’s trading partner management facility, and send only the minimal TP info that is necessary for back-end fulfillment into the internal enterprise.
• Define and manage the detail about the external interfaces (aka connections) at the edge.
• Deal with edge security and threats, as well as traffic control.
• Provide a mechanism to handle edge errors at the edge.

b) As much as possible, remove “connection variance” up front.
Each connection will have a:
• Technical protocol (file, service, message),
• Specific transaction type (enrollment, payment, etc.
• Specific trading partner (a trading partner is anyone on the outside that you “trade” with, including all partners, vendors, customers, and SaaS/ Cloud apps).
We want to use the edge gateway to remove these variances and generate a regularized business service request to push into the enterprise for fulfillment.

c) Use the edge gateway to maintain an inventory of all your connections to the outside world.
If there is no single place in the enterprise from which you can understand and manage all your connections, you know you’re in trouble. Much like identifying strategic chokepoints helped military leaders of legend defend large areas, we consolidate all the one-to-one connections from the inside to the outside of the enterprise and manage instead from a handful of abstracted end points at the edge gateway.
Only the edge gateway exposes itself in the handoff of data between numerous external requestors and internal providers, providing a mediating safety mechanism that is much easier to count and manage.

d) Design the Gateway to provide visibility (for both yourself and your customers) into the connections traffic, so you can provide proper customer service (including self-service) and audit support.
You want to monitor data that’s flowing back and forth across the edge and be alerted when things get stuck or slow down. For example, something out of the usual pattern may alert you to the fact that a data partner is being hacked.
This also empowers you to monitor trends and spot performance degradation. This insight helps you manage for efficiency and effectiveness over time — as well as provide BI value for internal partners who may benefit from insights into things like customer usage patterns.

e) Establish standard edge business processes/patterns (see Figure 1 next page)
Large B2C entities long ago figured out the value of established customer business processes. A bank, for example, cannot afford to build individualized processes for the way each customer wants to order checks, transfer funds or check account balances. Neither can you.
B2B IT environments are rife with individualized processes, which contribute to the mess at the network edge. This is unnecessary. CIOs should be engaged in normalizing repeatable processes, based on established use case patterns. This way, your project teams don’t have to figure out the integration process anew each time. This standardization supports cost savings, staff time savings and the strength of your brand over time in the same way that uniform processes at McDonalds give individual managers a sufficient, secure and repeatable template for any store, anywhere.

edgezonebp

In Conclusion

Due to the demand on IT departments, it is not uncommon for siloed, project-specific solutions to jeopardize the network edge and create technical debt and security liabilities along with the opportunities that drove the establishment of the connection in the first place.
Fortunately, the best practices outlined above can give IT departments a way to achieve lower costs and higher quality by establishing a structure, patterns and protocols — without upending budget, staff and other processes.