This is part of a blog series. For more details, start with the intro.
If you build an application today, you get laughed out of the room if you don't have an Application Programming Interface (API). You also get laughed out of the room occasionally, if you don't use standards where possible.
In terms of standards, we're talking both industry (open) and internal (proprietary) standards. In the enterprise, it's sometimes acceptable to use a proprietary standard in the absence of a semi-mature industry option because it's the architecturally elegant way to go about things. The point I'm making is, use one. Just make sure there's a standard, published way for teams within the organisation (and externally when required) to hook into common services.
The proliferation of systems across traditional enterprises that reinvent the wheel instead of reusing existing services is a joke. Unfortunately, this is the norm rather than the exception due to various factors, the most common being that the powers-that-be did not bother architecting, implementing and mandating a centralised, standardised way to reuse core services. Ultimately, this is really about the APIs an organisation makes available. More importantly, APIs have to scale. If not, no one is going to use it, even if it's mandated.
What the enterprise service bus and services oriented architecture marketing blurbs were promising a few years ago, agile companies are making a reality today. The difference is that they’re not doing it with enterprise web service standards like SOAP, which is too heavy for many of the use cases today. Everything is about REST. It’s a lighter weight, more natural way of doing things.
Like with most things in the technology world, the poor cousin of the API world is security. This needs to change. Security is the one thing that MUST be used across all systems. It is also the most difficult aspect to manage if you do not centralise it. Most organisations don't realise this until they have a huge mess, at which point it's too little, too late.
With the maturing security standards available today, there is no excuse not to bake security into how systems interact and also not to have common security services be centralised. OpenID, OAuth and SCIM are starting to gain real traction as they are REST-friendly and work well enough in the web-enabled world. In an enterprise setting, many organisations are starting to really explore these as options whereas in the past, many would insist on sticking with SAML, XACML and SPML.
In reality, many look at a hybrid model; instead of mandating a single standard for a use case type (e.g. federated single sign-on), organisations are relying on off-the-shelf software products to provide the range of support for the varying use cases required and using policies to determine the appropriate standard based on context.
An agile enterprise is built on interoperability, reuse and centralisation of key services. Security is one such service. The moving parts need to be secured and the common security mechanisms need to be centralised and made available to all systems. Standards and APIs are core to being able to deliver on this.
This brings the "Do security like a start-up or get fired" blog series to a close. If you missed anything along the way, head back to the start and catch up on the considerations you didn't get a chance to read.
Standards & APIs
In terms of standards, we're talking both industry (open) and internal (proprietary) standards. In the enterprise, it's sometimes acceptable to use a proprietary standard in the absence of a semi-mature industry option because it's the architecturally elegant way to go about things. The point I'm making is, use one. Just make sure there's a standard, published way for teams within the organisation (and externally when required) to hook into common services.
The proliferation of systems across traditional enterprises that reinvent the wheel instead of reusing existing services is a joke. Unfortunately, this is the norm rather than the exception due to various factors, the most common being that the powers-that-be did not bother architecting, implementing and mandating a centralised, standardised way to reuse core services. Ultimately, this is really about the APIs an organisation makes available. More importantly, APIs have to scale. If not, no one is going to use it, even if it's mandated.
What the enterprise service bus and services oriented architecture marketing blurbs were promising a few years ago, agile companies are making a reality today. The difference is that they’re not doing it with enterprise web service standards like SOAP, which is too heavy for many of the use cases today. Everything is about REST. It’s a lighter weight, more natural way of doing things.
Like with most things in the technology world, the poor cousin of the API world is security. This needs to change. Security is the one thing that MUST be used across all systems. It is also the most difficult aspect to manage if you do not centralise it. Most organisations don't realise this until they have a huge mess, at which point it's too little, too late.
With the maturing security standards available today, there is no excuse not to bake security into how systems interact and also not to have common security services be centralised. OpenID, OAuth and SCIM are starting to gain real traction as they are REST-friendly and work well enough in the web-enabled world. In an enterprise setting, many organisations are starting to really explore these as options whereas in the past, many would insist on sticking with SAML, XACML and SPML.
In reality, many look at a hybrid model; instead of mandating a single standard for a use case type (e.g. federated single sign-on), organisations are relying on off-the-shelf software products to provide the range of support for the varying use cases required and using policies to determine the appropriate standard based on context.
An agile enterprise is built on interoperability, reuse and centralisation of key services. Security is one such service. The moving parts need to be secured and the common security mechanisms need to be centralised and made available to all systems. Standards and APIs are core to being able to deliver on this.
This brings the "Do security like a start-up or get fired" blog series to a close. If you missed anything along the way, head back to the start and catch up on the considerations you didn't get a chance to read.
No comments:
Post a Comment