Y2.02K- The Enterprise Software User Revolt

What is Y2.02K?*  Don’t bother hiring Mckinsey, it doesn’t take a rocket surgeon to figure it out.  All you have to do is poke around your company to identify the one thing that people absolutely HATE about their job.  The thing that causes grey hair and un-necessary conflict:  You’ve got enterprise software that sucks.  Maybe it’s an old system, maybe it’s a legacy system inherited from an acquisition, maybe it was one

enterprise software

Y2.02K User Revolt

“sold” to you that never came close to expectations.  Whatever the cause, these clunkers are doing really important things…just doing them badly.

First Things First:  Its’ Not Your Fault

These enterprise software systems, when built, were “state of the art” at the time.  Have you ever even heard of an AS/400 mainframe crashing?  Never!   That was the state of enterprise software art at the time.   Doesn’t make it any friendlier, but in a way it wasn’t designed to be friendly.   Other systems may have “all the right buttons and functionality” but the underlying architecture is a dog’s breakfast.  In the data-centric competitive economy, this is the root of really exorbitant maintenance costs and more and more grey hair.

We also can’t discount that our perceptions of software have really changed.  Apple, Google and others drive the “iPhoneification” and gorgeous user design really highlight the value of great user design. Against this backdrop, old software just looks and feels horrible.

And Then This Happened.

Data!  Data analysis!  Predictive Data Analytics!  Listen, I’m not going to mince words here.  The data gauntlet is far, far out of the gate.  Managers and the C level are demanding analytics and they want it yesterday.  But to do this we have to grapple with our old crappy enterprise software systems.  These old software systems hide data behind a labyrinth of spaghetti architecture.

When we first built K3 one of our key fundamentals is that it has to be the WD-40 for data. Part of this is a simple grappling hook into older enterprise software systems (K3 adapter library) and the other half is seamless user driven transformation.  What do I mean by that?  It’s getting hooks into systems and then enabling users to sort, blend, harmonize the data so you can make sense of it and do new and cool things with it.  Call it a ring-fence, call it closing a digital divide, but in the end it’s all about closing the holes on monolith software.

Y2.02K is the User Revolt, and It’s Already Underway

Technology people with eyes wide open have been reading their news feed for the last few years with their mouths agape.  Why?  The new technology rolling out is staggering in simplicity and absolutely amazing.  The “first majority” of large companies are just now putting this technology to work and decoupling key aspects out of their monoliths.  The fact is these technological leaps and bounds coupled with the absolute fed-up disposition of users makes old monolith systems a lost cause.  At a minimum it will drive a powerful replacement cycle in favor of applications with newer technology.   At a minimum users are already reducing the footprint of monoliths in favor of external technology.

By 2020 the monolith is only for absolute laggards. Most large enterprises will have gone far far beyond this.  But the next 5 years are the most exciting the software business has ever seen. Fasten your seat belts.

*In case you didn’t get it.  Y2.02K is Year 2020.

What is an API???

When the Harvard Business Review, a wonderful publication that rarely gets deep in technology “solution-eering”, starts talking about adopting an API strategy,  it’s time to lend an ear.  If you have not read it, here it is in full:  https://hbr.org/2013/08/move-beyond-enterprise-it-to-a/.

I’m going to skip over the smart sounding techno- speak of Cambridge for a moment, and GET ALL THE APIhead Southside to talk about APIs and why they are so important in basic terms.

Let’s say you want a Pizza but there is no such thing as a pizza parlor.  To get a pizza you need a big oven, you need ingredients, and you need some pizza skills to put it all together and cook it to perfection.  Pizza after pizza, sooner or later you get tired of spending all this time in the kitchen.   Pizza making is a time sink on your day and you’ve pretty much boiled your pizza making to a regular set of steps for a reliable pie.  Maybe you can get someone to do it for you?

Enter the invention of the pizza parlor.  There is a person to manage and assemble the ingredients, another to work the oven and cook pies to perfection.   The pizzas come out great.  The staff is great at their assigned task ( but pretty bad at anything else.)   But there is one more important person.  The person at the counter.  No more fooling with ingredients, assembling or cooking.  All you have to do is go to the counter and say, “pepperoni pizza”.   Voila, 30 minutes later pepperoni pizza appears.

The guy at the counter?  That’s your API.   APIs abstract us from the rigors of what happens behind the technological counter of a piece of software.   With an API, I don’t have to touch or do anything behind the technological counter, ever.  As far as I am concerned, as an abstracted consumer, the dirty work stays a nice mystery.   And just like a pizza menu, I can order up any number of special items .  Just talk to the guy behind the counter.  No messing with ingredients (data), assembly  (“ETL”), cooking (processing).

So why is an API strategy so important?

  • 90% of the world’s data was created in the last 2 years.

Using the pizza analogy we now have a TON of ingredients in the fridge.  Spoilage is a real problem (lost/hidden data).  We have neither the time nor person-power to have people knocking about behind the counter trying to make their own pizzas. Think I’m kidding?  Just give a thought to all the CSV files a typical corporation deals with on a day to day basis.  These are useful little devils.  CSVs are useful in the sense that we really, really need the data within;  CSVs are devils in the sense that to use that data we have to get behind the technological counter and vlookup and code ourselves into a knot.

  • API s have evolved beautifully.

Back in the day the ways of ordering a pizza from the behind the technological counter guy was a bit cumbersome.   You had to order a pizza in a very specific and lengthy way.  Kind of like giving the pizza counter guy a secret password, special handshake, awkward exchange of pizza ordering language and salutation to the sun and moon.  Some APIs are still like this, but they have evolved a lot.  These days it’s all Internet speak (Web Services) and has been simplified to the Nth degree (REST).  At BroadPeak we joke about companies that talk about “integrating” into  REST APIs.   If you think about it, saying you have integrated to a REST API is like saying, “We integrate into the thing that is absolutely and thoroughly designed for integration.”   Well, good for you!

Yes, API ’s Have Gotten This Good

How good have APIs gotten?  Good enough that there is a bit of a movement pulling away from traditional notions of SOA (service oriented architecture).  The truth is we don’t really care what applications are doing in the pizza kitchen.  So long as we have a single place to call.  When deployed across the enterprise it eliminates the need for clunky service busses and ESBs.   So, rather than spending millions of dollars on a TIBCO implementation with a high failure rate, we proliferate APIs.  Our developers spend their  time building really cool applications instead of costly data marshaling.

Oh so much more to come. Stay Tuned


New Buzzwords You Will Hate by 2016

The New Buzzwords You Will Hate by 2016

Freshly returned from yet another conference.   Since its nearing the end of year I thought I would put out a semi-prediction about what everyone is going to be buzz-wording about in 2015.

“NO ESB” –  The agenda behind the NO ESB movement is this:  Stop thinking about shutterstock_225839086message busses and start thinking about APIs.  It’s not bad advice.  Large Enterprise has been crippled by old legacy systems without APIsfor so long. In the old days we used to dream about connecting all systems by a ubiquitous message bus.  90% of the time these projects failed miserably.  The alternative?…API everything.  Of course the NO ESB camp has already schism’d  saying that it’s not NO ESB but NOT ONLY ESB.

I’d say use what is right for the purpose, but yes, 2015 is the year of the API.  Like a daytime soap opera we will be spending hours transfixed on “The Old and the REST-less.”  Get it?

“Microservices” –  This one right out of the gate is already getting old.  But I guarantee you are going to hear more and more about Microservices! Microservices! Microservices!  What is it?  Not much.  It’s basically the same old service oriented architecture except a bit more granular.  Like SOA its all about componentization.  But with Microservices you might break that up even further with some nice API (hopefully REST) exposure.  Think of it as SOA for Millennials.

“NO IT”- This one is actually kind of neat and long overdue.  Back in the old days, (EyeTee) sat in their ivory towers dictating how operations will run.  This got morphed into running IT as an internal business, where business operations are treated as clients.  According to NO IT, this is all over.  Remember Neo in the Matrix: “There is no spoon.”  With NO IT, there is no IT.  According to Gartner,  40% of technology spend is coming directly out of the business, not IT.  For that matter, what it really comes down to is the  pace of business just can’t wait a week for a technical adjustment.   NO IT simply states that Business Operations are not your minions and they are not your clients.  They are your peers.  NO IT dictates that technologies get out of (Eye Tee) and fold themselves directly into operations.

Of course it’s only a matter of time before someone re-defines NO IT to mean Not Only IT.

“DIY BI” –  DIY BI is freaking awesome.  Back in the olden days (2001) we had the same need for slick customizable reports as we do now.  The trouble is that the data we need is all over the place.  Someone came up with a clever idea of an “OLAP Cube” that batch runs, summarizes and dimensions the data.  Cool but ornery to setup and impossible for real time reports.   With the advent of Tableau, Spotfire and QlikView the cube era is OVER- Gone the way of MySpace.  Any old regular business analyst can park Tableau on top of data sets and create really cool reports and dashboards.  As always, 90% of the job is data marshalling.  (See Citizen Integrator Below)

“Citizen Integrator” –  The Citizen Integrator is a real milestone in technology.  Integration tools, like our very own K3, have been designed to let regular, non-technical, people create and run integrations.  Compared to old integration tools, it’s a major milestone in abstracting users away from coding.  In a nutshell Citizen Integrator takes your average Joe or Jane and turns them into a data marshaling powerhouse.  How?  (see Data Scientist below)

“Data Scientist” –  It’s  like a job title from the future.  Meeting someone with the title of Data Scientist is akin to meeting the President of the United States: somewhat within the realm of possibility, but a rare event.  My gut tells me we are going to hear more and more about Data Scientists in 2015.  So what is it?  In truth a data scientist is 70% data wrangler. To see what I mean ask yourself:  Does a snapshot of your morning sound something like “VLOOKUP, VLOOKUP, IF, IF, IF, THEN, TRIM, HLOOKUP, CTRL+D, IF VLOOKUP?| Select *, Join”   You might be a Data Scientist!  The balance of the workload is doing analysis and reporting.  Remember DIY BI above?  Well, Citizen Integrator + Smart Analysis + DIY BI = Data Scientist 2015-Beyond.

“IOT” –  Don’t worry, not yet another acronym to learn.  It’s just “Internet of Things.”  You know how cartoons late in their run will do a mashup with another cartoon to squeeze a bit more mileage out of it?  This is pretty much the same thing.  The powers that be crunch it down to an acronym to get another year of buzzword out of it.  Yes.  I’m sorry.  It looks like another year of vapid conversations about how our toothbrush and toaster can talk over WiFi.

Last but not least:

“DevOps” –  If you think that Microservices might get on your nerves, prepare for DevOps.  It’s already being badly abused,  DevOps is nothing more than how you conduct “development”.

These are all good attempts to describe the frenetic pace of change in the tech world…but buzzwords…please stop…please just stop.

Designers will be Data Artists

Here is a great article discussing future transformations for designers.  The future is all about Data.  So if you aren’t yet tired of hearing about BigData, you may soon hit your breaking point.  If this article is correct, it’s only going to be a growing phenomenon.

The question for leaders is…

How are you empowering your data artists?

Drinking directly from the Big Data Firehouse?

A user-driven integration layer between BigData stores and BI Tools is a MUST HAVE to crafting meaningful data analytics.  If you are instead connecting BI Tools directly to Data Warehouses, then this


is how your data analysts feel when trying to curate data stories from that hose.

This article discusses how the latest from Salesforce…the Wave…doesn’t handle this problem.  But there’s no reason you can’t solve this issue simply by adding a layer that allows users to judiciously curate data from the data warehouse.  The challenge is about finding tools that empower users to integrate without requiring a PhD in Computer Science. Hint hint…we’ve got one of those tools here.

An Enterprise Integration Tale!

We developed a whiteboard video.  Had a blast doing it.  Check it out by clicking the pic below!

Its Alive




Biggest Waste Infographic

4 Questions REMIT RRMs Don’t Want You To Ask

As we move forward with REMIT there seem to be a lot of entities with stars in their eyes that they want to become an RRM.  RRM is the Regulatory Reporting Mechanism under ACER that facilitates the reporting of transactions.   This seems like a fairly straightforward thing.  Setup a facility to receive values from the TRUM (Trade Reporting User Manual) and go sign up some clients.  Easy.

Anything but!  Running this type of facility is not for amateurs.  In short, there is zero tolerance for security holes.   Frankly, we all need to think about what happens when this data gets hacked.  Sorry to sound like a sour pill, but that’s the reality of the world we live in.  Just ask Target.

Got SAS 70?

Got SAS 70.

Can You Describe in Detail the Elements and Auditing of your NOC?

A NOC is a Network Operations Center. What you are looking for here is a SAS70 Type I or II audit.   The SAS70 was put out by the AICPA in 1992. What you are really looking for here is a SAS70 Type II audit which is a “reporting on controls placed in operation” and “tests of operating effectiveness. That this assumes is that the RRM has a complete set of controls in place and that they have been tested.  Many corporations maintain policies that only permit sending sensitive information only to SAS 70 Type II facilities.

Can You Please Identify Named Engineers, their Certifications, and contact Escalation Procedures?

When Armageddon happens, and we have to assume that it will, the last thing you want is to have a team sitting around wondering, “What do we do?”  There should be an escalation procedure in case of a “major event” that your team can follow to ensure that you are not left at the end of the line.  Likewise, certifications in a NOC are important.  There is rigor around these programs and having a named set of engineers prevents the use of vague, 3d party, facilities that the RRM really has no idea how they operate.

Can You Please Describe Your Penetration Testing Policy and the Summary Results of Your Latest Test?

Penetration testing is the industry standard for figuring out whether a particular deployment has any holes in it.  Generally a third party is engaged to “test hack” the infrastructure to determine whether there are any holes.  It’s not bullet-proof but significantly diminishes the probability that some kid with a laptop can hack into the system.

Can You Please Provide the Details of Your Independent Compliance Program?

Satisfying the requirements of ACER is more than just shipping trades to a fancy database.  There are an enormous amount of controls that need to be in place to safeguard the data you are sending to the RRM.  One of the largest risks, besides hacking, is some type of an internal job where someone leaks information that they should not have been able to get at in the first place.  The only way to control this is a serious implementation of a compliance program that oversees data access and its use.  Part and parcel of this is the notification procedures in the event data is lost.

Regulatory compliance is one of those things firms wish to complete and move away from so they can focus on their core business.  Problem is, you are shipping sensitive trade data and should be asking as many questions about this aspect of your preferred RRM or Trade Repository as you do about their service capabilities.  Simply following the majority consensus may not your best bet.

SAAS Integrators feeling Sassy

The accelerated pace of technology development has brought about a deluge of confusing buzzwords.  Even if you came to the smart conclusion that technology is key to your today’s competitive strategy, crafting that strategy and finding suitable vendor partners to execute it is increasingly difficult.  Not only do you have to understand a growing list of new topics and capabilities, you have to wade through the marketing hype to avoid spending money and effort on froth.

Put your Big Data in the Cloud!  Get off your SAAS!  

Okay, no one actually says that last one, but does any actually understand what half this stuff means?  Let me let you in on a little secret…that’s the point.  In the face of a hash tag cloud of confusion it’s tough to make decisions.  And that confusion is what marketers prey on.

My favorite example from the software integration world is…

Look How Easily We Integrate with SAAS Applications!

If you have searched integration software in the past year, you’ve most likely seen marketing buzz around how easy some of them can connect to the latest SAAS applications.  Let’s be clear, there is little magic in simply connecting to something that by definition makes connections easy.  See, SAAS applications (Salesforce, Workday etc.) get their scale by being standardized across the board and easy to deal with.  So a vendor marketing that they connect to SAAS easily says more about the SAAS provider than it does about the integration vendor.  That being said, if the vendor can simplify how the data from the SAAS application is managed and how it is harmonized with your legacy systems, now we’re talking about enablement via SAAS.

If you do it right, you may even be able to leverage big data analysis in the cloud through integration of legacy infrastructure with your SAAS footprint.  But the simple connection to your SAAS applications is a small step in that journey.

BroadPeak Presenting at ICE’s Trade Reporting Workshop in Calgary

BroadPeak will be presenting at the ICE Trade Reporting workshop in Calgary next week (August 27). Who doesn’t love Calgary in the summer?


With compliance officers now focusing on Canadian equivalent of Dodd-Frank regulations, the workshop is a timely resource. The workshop will give participants insight into the regulations, their likely impact as well as ICE trade repository services. In addition Gordon Allott from BroadPeak will be presenting on how to meet the technology challenges of reporting in a session entitled, ‘Canadian Reporting Integration & Implementation’. Gordon will give insight and anecdotes from customer experiences using K3 to automate reporting across North America, Europe and Asia.

Are you attending the workshop? Any burning technology questions that you would like answered?

With participants ranging from physical to financial and from 100 people firms to super majors, it should be a very interesting and rewarding day.

Page 5 of 11« First...34567...10...Last »
(877) 738-0470