Frameworks and Cavemen
People need to frame things all the time. Saying that the world has become complex, it's the same as saying that things have become more unpredictable. Not knowing, not controlling what is going to happen, or simply not being able to let go, it's not possible for most people these days. So they need boxes. Boxes where to put things, archive them, and then move on with their lives happy to had been able to again transform complex things into something that is now apparently simple and predictable.
I've always been a firm believer that you need to be able to live with things you can't control, understand or master. The classical circles of influence. But there is a trap in this behavior! If you don't question things around you, if you just believe in your 5 senses, you'll never be able to expand the boundaries of those circles. Creating intersections between circles is one of life's great lessons, until they don't become circles again, and then you find yourself between a rock and a hard place because the rest of the world don't seem to be able to box you anymore. But this is people we're talking about! People are complex and unpredictable. It's in their nature. But what about processes? Wouldn't it be expected that processes could be boxed more easily? A perfect process framework could last for ages, with all those work flows tightly integrated and organized! No unpredictability, no noise, no fuss. Perfect playground for technology to enable automation and achieve maximum efficiency and optimization. I'm sorry to tell you the hard truth, but processes are not like that anymore, nor they never been that way. Ever. If we take the process of hunting in the paleolithic as an example you would see that cavemen never hunted the same way. They had their techniques and tools, some strategy and lots of tactical plays, but the hunt always turned out to be a different play every time it took place. This is why any framework has to be flexible, open and most of all, extensible. So why can't technology cope with that?! If cavemen wanted to start hunting different breeds, in different geographical landscapes, they would never expect the same tools & techniques to work at the first time. They knew that some adaptation had to be done, and that sheer fear for one's survival was always a big tip on when to run or to stay foot. Change or not. Risk management was always there.
A different breed of people is needed
Today everything is a system. If the National Citizens Registry system tells that you're dead, you better be or you'll have a hard time proving otherwise! The simple fact that a living person is breathing and talking in front of the counter might not seem to be proof enough for the person hitting that keyboard, not even crossing eye sight with you. Businesses everywhere are looking for a more organic view of the processes, to avoid this "systematic" approach that has been proven to create an artificial sense of order.
Someone has to step forward and shake things up, not draw more boxes! Someone that understands the business strategy and uses the knowledge of "systems" limitations and strengths to suggest a framework that can be both durable and flexible. Someone that is not bounded by the circles of tools & techniques, not bounded by boxes of processes and work flows. Someone that out of all those business requirements, technology adoption limitations and organizational complexity will help businesses hunter and gather more customers, more revenue, and not stay in the cubicle doing point and click.
I would like to believe that this someone is the enterprise architect: an enabler and not an owner.
So what is Enterprise Architecture?
One way of definition something is saying what is not! Enterprise Architecture (EA) is not about organizational engineering, and definitively not about technology. It's about helping organizations build capabilities they don't have, or enhance the ones they want to grow. So it's about change. I'll try to move away from academic definitions here and that means leaving more blank spaces than usual. Saying EA it's about change is enough for now!
The divorce between Business and IT
One thing that most people have struggled with in my midst is being able to grasp the true essence of EA. Probably because I still deal with very technology bounded people, even the ones that like to call themselves: "You see, I'm not a technical guy/gal". In the Information Technology (IT) arena where I work, there is a blur where this hairy and unpredictable thing lives which is called: "Business". The actual reason for IT to exist, the place where people more suffer when IT does not work, and the real market for IT to make money is all there: business. And yet, for "business people", IT is filled with mystery and uncertainty! More than once I hear people saying that something went wrong on a new XYZ Project because of IT and they are so frustrated because "IT people" nor don't want or simply don't have the ability to put it down in simple terms so "business people" can understand.
When this frustration from "business people" rises to executive levels, it's time for the blame game inside IT! A time consuming and useless witch hunt. Technology these days augments tremendously human mistakes. So just by clicking the wrong key, a person can single handed bring down IT systems that are supporting automation tasks or front office desks and it's mayhem. Underneath all this stress there's a common cause: divorce between "business people" and "IT people". The first ones want systems to "just work!" and the second group has a tendency to over complicate things (some use machine language just to cover for their lack of social skills). They feel that it's too hard to explain in simple terms, drowning them and everyone around on a pool of acronyms and artificial challenges, while business stands there waiting for the crappy app to stop cranking!
Why Business Intelligence and Service Integration tend to fail
Anyone that even tries to get in the middle of these two groups would feel the level of power in this invisible force field pushing those two groups apart. Two examples are teams trying to set up a Business Intelligence (BI) capability or teams trying to create a Service Integration (SI) platform. Boy do these guys suffer!!
BI is all about servicing the key business stakeholders with aggregated information to help them decide based on either the past, present or future (forecast) information. Financial analysts, marketing people or planning and sourcing leaders all complain about the same thing: we never seem to get information when we want! It's such a monumental task, that some of them start their own shadow IT departments, wasting more time with technology than with their actual business responsibility. Gotta love these people! They have a job to do and they don't understand what the hell is that army of techies doing on floor minus 27.
The other group of middle people that tend to suffer from this dismantled situation are the ones in charge of setting up a process workflow based in common services. Reusing logic but most of all decoupling logic from process workflow is the ultimate goal. Also the fact that a central repository of services could be used to implement any new or enhanced process is one of the common goals we see in these projects that use a reference architecture called SOA (Service Oriented Architecture). Anyone working on any SOA based project rapidly becomes or toughens their religious belief. It's like a mirage, and those few projects that can claim some success were the ones that either started departmental or at a certain point in time decided to restrict the scope. Most of the times because "business people" can't seem to see the value of this, or they like to have their own "way of doing things" and from an enterprise perspective this DYI mentality can cost companies lots of money. They don't see these Service Integration projects as a way of reusing good practices, enhance collaboration and set the stage for a more sustained growth. But the stiffness of processes is sometimes jelly compared with the stiff way some people defend their processes and their realm ultimately.
So what seems to be the answer?
It's clear that EA can't solve all problems just by standing in the middle and trying to reconcile. There are limitations within every organization that clearly spread beyond the depth and breath of architecture, specially when some of them belong to such a variety of pathologies like:
- Lack of communication between people and sections,
- Organizational agendas,
- Political environment between departments,
- Excessed or relaxed security procedures
- Blurred Business Strategy
- Tendency to solve HR problems with technology
But at least EA is a starting point, because it has:
- Open and flexible frameworks
- A common languages and methodology
- Focused on business requirements that come from different stakeholders
For me the biggest value of EA is to make sure "business people" understand that they don't have to be IT bounded, and make sure "IT people" understand that IT is just a means to an end and not the end itself. The best way to achieve this is by creating an EA capability inside a company that would help business and IT people communicate in a mediated fashion by enterprise architects. There will exist experts in business processes (Business Architects) and experts in IT processes (IT Architects) but it's the enterprise architecture job to make sure they reconcile so "change and growth" are enabled while aligned with the Business Strategy and Vision.
Where do I stand?
Currently inside Oracle I'm using EA principles and techniques to close the gap between Oracle sales people and customer IT executives on opportunities related with Engineered Systems. I do it for the 128 countries that comprise the EMEA region. I have to drop by a different country every time and find that cultural differences aside, these gaps are astoundingly similar from region to region. A language of value is most of the times the best way to elevate the sales pitch, but when it comes to the actual sales play, IT executives and managers seem lost in this plethora of technical jargon. This is when it's time for an architectural approach to step in. We call it "just enough" architecture as we don't have time to spend countless days in each customer, but more than once we get the chance of either sit on those architectural boards or interview "business people" and "IT people". The innovation, modernization and agility that businesses so desperately strive for can not only be achieved by technology advances, but if placed in the right architecture this vision will prevail regardless of the products implemented. To understand this vision I have to sit down with not only IT executives, but also business owners and other key stakeholders inside an organization. And that's why I pick so many planes.
From a company seen as wanting to push products and services, this stepping back and rethinking things approach as proven to influence and enable more. Remember: we're the enablers not the owners.