What architects should be doing (and mostly aren’t)

Suppose, just suppose, you are called into the CEO’s office. Then suppose the CEO says “justify this group called enterprise architecture”.

What are you going to say? — because “well, everyone else has one and so we need one too” probably isn’t going to do your career any favours.

The Setting of Bounds

Enterprises are complex adaptive systems operating in a complex adaptive world.

That’s not just a “phrase of the month”. It points to enterprises as places where initiatives stem from multiple teams, not under the direct control of the people at the top — and that, to succeed, that kind of initiative has to be the norm.

For a Chief Information Officer, that means that there will always be IT-related work being done elsewhere than in the formal IT group. In an era of smart phones and tablets, cloud-based services, and personal computing software capable of processing more data than the mainframes of thirty years ago would have been comfortable crunching, how could it be otherwise?

Now, as anyone who’s ever organized anything knows, there’s a balancing act involved in letting the thing happen with optimal results. Too many rules and boundaries, and the initiative and ability to coalesce around what’s working is hampered or even stops. Too many consultations, and nothing happens but talk. Too few bounds, on the other hand, and the channelling of energy toward the optimum also stops as efforts dissipate.

So the first job of the architects is to lay out the playground (so to speak) — setting some bounds and conditions, but otherwise leaving the field free for initiatives (solutions) to emerge.

Even ten years ago, it was different: there were far fewer options available for those who wanted to create their own solutions (and their cost made many of them more visible) and much of “architecture” was replacement of application portfolios with packaged solutions.

Today, in an era of “bring your own device”, “bring your own application”, and cheap points of entry, setting the bounds that channel these into paths where integration can occur is a useful service — far more useful than acting as the gatekeeper for absolutely everything.

Integration of the Parts

Getting disparate parts to work together is the next and equally important role of architects.

More and more systems are integrating with non-IT components (I call them “non-IT” because the suppliers involved are not traditional IT vendors. This is both a result of the digitization of most other lines of business, and the ability to sense more of the world using the emerging “Internet of Things”.

From sensor antennae reading RFID chips on selling floors and plant floors, to sensors tracking body heat to see traffic patterns, to digital broadcasting equipment, to a host of other devices, what has to be made to work together goes far beyond the things the IT group traditionally dealt with.

Cloud-based suppliers, in turn, put applications beyond integration by modification. Moving data in and out of them now requires that transforms or insulating layers be built where needed (for instance, to inject data into your ERP investment).

Architecting these as utility infrastructure — in-house middleware, if you like — rather than building individual “connectors” on an ongoing basis is the lower cost, longer term way to deal with “too many moving parts” — and to make intermediate data available for analysis (or even sale as “data products”, if your line of business supports that).

Bringing down the Total Cost to Own and Operate (TCOO)

A project hits the bottom line once, its outcome preys on the bottom line year after year.

Architects should be expected to have a sense of the cost of following one set of options for IT over another — and to ensure that the enterprise, over time, brings its total cost to own and operate its information technology down.

Some of the items become bounds within which people make decisions; more of them are recognizing that as parts are integrated and updated the long term direction should be upheld.

This is why, for instance, the boundary condition “licensed code shall not be modified” might be put into play — it removes future cost from TCOO for retrofitting mods, and removes the upgrade limitations modifications impose (from an unwillingness to pay again).

At the same time, another boundary condition about security requirements might be put into play, even though it ostensibly is adding cost, simply to ensure all the moving parts will play well together without creating anticipatable exposures to the firm’s assets.

The Upgrade Cycle

Multiple factors come into play for existing assets to help determine their lifespan. It should be expected that your architects are tracking these and injecting upgrades into the mix as needed to keep the asset portfolio operating without cost increases.

This means knowing and projecting the market value and availability of required skills, the value of new features from vendors (to know when to upgrade), the cost profiles of various platforms, and the opportunities to extract additional value from investments through deployment changes are all roadmaps you should expect architecture to be able to speak to — as well as give guidance on accelerating or extending depreciation and funding operating costs surrounding replacement in each year.

Differentiation Criteria

Architects, finally, should project likely risks, reward ratios, and zones of opportunity for differentiation in the portfolio. This sets a bound for project release that creates a favourable zone for provisioning code that differentiates the enterprise.

In general, differentiation produces new value on the top line, whereas commodity solutions support existing operations. The first deserves your best customized response; the second is implemented and maintained purely to reach the lowest possible cost.

Without having worked through potential zones of differentiation, architects really have little to nothing of interest to say to the business (as many, many meetings over the past decade have shown). With it, they become contributors in the process of building the future.

So — if your architects aren’t working on these — why not?

Posted in Enterprise Architecture | Tagged , , , , | Leave a comment

When will enterprise architecture really make a difference?

It’s been around for over a decade, and, frankly, in most enterprises, all it’s made are enemies.

It’s “enterprise architecture” — or, as other parts of the business know it, “those damned do nothing laggards”.

Architects are far too often seen as swaggering into meetings, ready to tell everyone else what to do and how to do it, then taking forever to actually deliver anything.

Resolve binds the enterprise has put itself in? Think through value propositions so as to fatten the bottom line? Keep an eye on the total cost to own and operate the asset portfolio? Actually advance the enterprise towards a well-crafted future state?

Surely you jest. It just doesn’t happen anywhere near often enough.

There’s a couple of reasons why. First of all, in most enterprises, enterprise architecture is an add-on. The core is still the fixed development/maintenance team, aligned with a portion of the business. They think they are in the business of researching the future state, figuring out the steps to get there from here, and, of course, design and deliver all required solutions.

Then you have the unit that got overlaid on the organization just ahead of architecture: the relationship managers (or client managers). They, too, see their raison d’être as understanding business needs, researching solutions, and advocating for them.

So the typical enterprise now has three different units in the IT group all figuring they should determine the future. Did that help clear up some of the doubts about the claim that architects have made a few enemies?

But those enemies are not just within IT, adding friction and cost to everything that’s done. (Let’s leave aside who’s responsible for adding the friction at this point, and simply say that it exists, is palpable, and the trail of delays and costs run up is easy to find.)

No, they’re out in the business areas, too, where nowadays there’s generally an investment in so-called business analysts who — believe it or not — think it’s their responsibility to determine the future and how we get there from here.

What enterprise architecture is supposed to be doing is laying out the big picture. If anyone should be carrying forward ideas like “here’s our roadmap to reduce the total cost to own and operate our portfolio (TCOO)”, or “here’s the analysis on why we want to remove all the mods from these packages and what it means to the enterprise’s cost and value profile going forward”, or “here’s the notion of building intermediate data forms and a data bus to insulate connected portfolio elements, each on its own vendor-created change cycle, to minimize change costs in the future”, it should be the architectural team.

Instead, what I see as a consultant is architecture groups more concerned with turf wars than actually making a difference.

In one large financial services organization, for instance, it was the development/maintenance team leader who drove a multi-year removal of all mods from their ERP system, leading to massive future cost savings, a rapid change cycle forward, and more architectural progress toward a unified information architecture than ten years of the EA group had managed to make.

In another utility operator, architectural progress was made by the person responsible for the infrastructure, who took on the project of application replacement leading to a whole platform removal, the TCOO improvement from virtualization, and the rationalization of the portfolio from 600+ elements to 150. The enterprise architects were still in meetings three years later claiming it couldn’t be done.

A decade ago, META Group’s Enterprise Planning and Architecture Service (EPAS) laid out the core enterprise architecture process flow. Create or update a future state definition based on the core enterprise business strategy. Figure out a statement of change required and prioritize it. Ensure the changes advance the business, information and technology (TCOO) architectural principles agreed from the governance process. This informs the project portfolio. Solution architects then merge business analysis and qualitative requirements with that delta statement to come up with a set of specifics associated with that project to design a solution to bring the future state closer.

Why isn’t it happening? (The flow through to the bottom line bears no relationship to the ROIs projected, after all, something you can find out by looking at the quarterlies for any public company and asking what the minimum ROI to get popped off the backlog was in their firm.)

Now you may say, at this point, why hang getting those results on the architects? It’s a good question, because project management, a general lack of deployment support, and a refusal to measure in the business to improve results all play their part in that failure to achieve results, too.

But there is an old Yiddish expression: “the fish rots from the head”. EA is supposed to be the head of the process advancing the future.

On that score, it’s failing.

It will start succeeding when architects come into the meeting prepared to discuss the deltas, be firm about the rules required to manage TCOO, and arrive willing to deal in a complex state of work (where safe-to-fail experiments are used to resolve disagreements amongst the business-relationship manager-solution team-architecture table rather than endless complicated work domain discussion that alienates everyone and racks up cost and delay).

Until then, expect EA to be an continuing expensive drag on getting anywhere from here.

Posted in Enterprise Architecture | Tagged , , | Leave a comment

IT filled with teams “preserving knowledge” is doing it wrong

Information technology groups tend to be quite persistent.

The excuse is “preserving knowledge”. Preserving hard-won knowledge of the business area served by the team. Preserving hard-won knowledge of the guts of the systems built by the team.

If you need either, you’re doing it all wrong most of the time.

Let’s take the second case first: knowledge of the system. Yes, I know you have ruthlessly modified your packaged software to meet the needs of the business over the years.

The question is: should you have?

Unless the code in question provides a value-generating, bottom line-visible differentiation of this enterprise from its competitors, what’s that mod doing there?

Was it because at the time no one in IT had the strength of character to tell the business that, when the answer is an imported best practice in the form of a software package, they change, the code doesn’t?

After all, if the package was unmodified, the enterprise wouldn’t have had to pay for the original modifications — wouldn’t be paying for the maintenance team year after year — won’t have to pay for the retrofitting of that suite of changes when the package is updated next time — and, oh yes, would be getting value for money out of the 22 per cent being paid for “maintenance” under the software licence by being able to easily move with the vendor when fixes and new function are delivered in new releases.

That’s an awful lot of money off the bottom line for years simply because no one was ruthless enough to say “no, you take the change” and make it stick. (Not to add ten years’ worth of depreciation expense coming off earnings per share, or taking the write down to fix this mess now.)

Maintaining code-level knowledge for home-grown code that differentiates the business and thus allows premiums to accrue — revenue others can’t capture, price premiums, etc. — makes sense. For everything else, it’s a commodity world, and that means the business changes to adopt the practice the package implements.

Now, back to the first excuse: knowledge of the business.

Can we be honest for a moment? The only people who truly know the business are the people in that part of the business. Senior management doesn’t, and all the Sarbanes-Oxley Acts and pretentions otherwise through restriction in delegating authority won’t change that. Other parts of the business don’t (they have quite enough trouble keeping on top of their own issues, thank you very much). Why should IT think that, by magic, they do?

IT people are not customer-facing when the part of the business involved is. IT people are not plant-floor sensitive, when the part of the business is. Good heavens, IT people can’t really enter into the financial mindset even when the head of IT reports to the CFO (mostly because they aren’t trained as CAs, CPAs or CGAs, nor do they work with the numbers daily so that errors become obvious and patterns of what needs to do are ingrained).

If “preserving knowledge” was so all-fired important, you’d never see a consulting firm win a systems integration contract. They’d have no preserved position to work from, and so would lose against in-house staff every single time.

Is that how the last twenty years have unfolded? Thought not.

Likewise, does your managed service provider, your co-location provider, or your telecommunications provider lock people into place for years so that they can “preserve their knowledge of your environment”? Or do they come and go, flex in and out, restructure at will without telling you, and still, somehow, your data centre and networking needs get met?

Don’t turn around and say infrastructure is different. It’s precisely the same problem, when you’ve got an enterprise architecture that can be summed up as “the answer is a package, what was your question?”.

Pre-configured service offerings, and pre-configured software, are one and the same thing. They’re items where you can mix and match parts and tweak check boxes and parameters to do something where knowledge preservation isn’t a big issue any longer.

So that leaves the last bit — the project backlog — as the remaining justification for permanent IT teams aligned with the business.

But that, in turn, leads to the myth that “we’re working” on unfunded projects, or projects not approved for release this year, simply because the team is underemployed.

IT organizations would be far better off if they did three things:

  • First, spend time on differentiation, and be ruthless about implementing packages in unmodified form. This forces the architectural conversation with the business into issues of strategy and tactical advantage, with the resulting myth-busting a plus for all concerned.
  • Second, if the project isn’t approved to go, stop working on it. Instead, build a team that can explore ideas (pre-project). This reduces the commitment level while allowing issues to be dealt with early (like finding out you have two parts of the business that disagree about what a supplier or customer is), and keeps solution selection to the end of the pre-project period where it belongs.
  • Third, acquire the necessary consultative skills to be able to gear up your knowledge when and as needed, bringing true skill in IT and its marketplace when you do. That’s how the SI firms do it, that’s how the outsourcers do it, that’s how the offshore teams do it, and that’s how you ought to do it to add value to the enterprise you work for.

Let’s be clear: if your project portfolio is filled with a lot of things to which commitments have been made but won’t see the light of day for years, your asset portfolio is filled with immobilized code that can’t be easily upgraded, and your headcount is filled with people who are stuck in place because of the need to preserve what they know, you are in trouble, both as an IT group and as an enterprise.

There’s only going to be one solution. The hard work of fixing what exists. Start by getting rid of the myths on the people side: it’ll make the rest of the puzzle more obvious to all concerned.

Posted in Enterprise Architecture, Human Resources | Tagged , , , | Leave a comment

Top level metrics for the business to direct IT

Suppose you’re a non-executive director on the Board. Or a C-level officer of the enterprise. Maybe you’re the country manager, or divisional general manager, of a piece of the organization.

What should you be looking at, to judge and give strategic direction, to whomever looks after your IT?

Stop right there, if you’re ready to point the finger at the Chief Information Officer and say “that’s not my responsibility, that’s hers/his”.

You don’t get to abdicate your responsibilities when it comes to other areas of your domain. It’s not your corporate lawyer’s responsibility to worry about all the elements of the next deal you do — they merely turn what you want into a contract you can live with if, heavens forbid, it ends up in litigation. It’s not the Vice-President of Human Resources’ responsibility to ensure that you have nothing but top talent in your organization: they may post the openings, screen the inbound résumés, and handle a thousand and one other tasks surrounding people, but who gets hired, how they perform, and sacking them remains your duty.

So let’s look at what you should be asking to see.

Projects are about results

Most people believe that if they just sort project proposals by some measure projecting their results — typically, return on investment (ROI) — and pick the best ones, they’ve exercised oversight.

Sorry. If that were the case, you’d be seeing (more or less) those results flowing to the enterprise’s financials. If you never approve anything with less than a twenty per cent ROI, shouldn’t you be seeing those results?

Are you? Did you even look?

There are a vast number of reasons you’re not seeing the results, but only one measure tells you what’s actually flowing through the veins of the enterprise: actual return on investment obtained (AROIO).

This gets you out of the weeds of projection and into the cold, hard light of reality. It also stops the finger-pointing cold, since getting results is inherently a joint effort of your IT resources and your business people.

Your goal should be to bring AROIO closer to your projected ROI year over year. That means the enterprise as a whole is getting better at projecting and estimating, better at execution, and better at deploying change and ensuring your results are delivered.

Did the light bulb just go on? There isn’t anything about AROIO that’s specific to IT, is there?

AROIO, in other words, applies to all aspects of the enterprise: it is a way to track changes in organizational effectiveness. If you’re a Board Director, it’s a tool to judge the effectiveness of management. If you’re on the senior leadership team, it’s a tool to judge your organization. (Best of all, get better at it, and you’ll start producing better results all around.)

Assets are about improving leverage

The other side of the equation is found in the asset pool. This sinkhole of past decisions is an essential part of the enterprise — you wouldn’t exist without it — but it needs to be directed intelligently.

Avoiding fads, and (equally) avoiding the fad of being overly cautious about change, is a delicate act.

Intelligent, strategy-level discussions about the assets involved in IT can take place only if you get them out of the individual products and services end of things. Tracking and providing direction around the enterprise’s total cost to own and operate (TCOO) its base would work well here.

What TCOO thinking does is force the IT side of the enterprise to think about technology change differently. Their goal should be to slowly but surely move the total cost of the portfolio to the lowest point the market currently sustains. It’s a journey, not a destination — new products and services are constantly coming into play, and changes in the enterprise’s demand levels affect what’s spent.

But there’s also an inclination, throughout the enterprise, to keep adding onto what exists rather than periodically going back and cleaning up. There’s a passion that small practices that are comfortable be carried forward into the future no matter what it costs over the next decade to make that possible. There’s a comfort with what’s already known (so please don’t change it).

IT, too, is filled with people who make their living from very specific and often non-transferrable skills. They will always have one eye on their personal security, and if that means the enterprise pays more for the next ten years, well, that’s not their problem.

Again, this is a trend measure, not an absolute. There’s no magic “best practice” on TCOO beyond “improve it year over year”.

Since TCOO encapsulates decisions such as outsourcing — it’s just another cost curve — it can be used to project possible strategic decisions such as ripping up the current application portfolio and replacing it with new packages, moving from in-house operation to an outsourced environment, mixing cloud services with in-house ones, hotelling of staff and telecommuting vs office environments, and a host of other choices.

Did you notice, again, that you could apply TCOO just as well to business decisions? How many service centres or outlets to have? What goes on the plant floor?

These two measures, AROIO and TCOO, are the gateway to being able to provide strategic insight to those in charge — and strategic direction back to the enterprise about IT. Asking your CIO to implement them, and to report them with analysis, is a good way to ensure that executive and director time is turned to productive uses.

Posted in Governance | Tagged , , , | Leave a comment

“If an experiment is sweet, you go ahead and do it” doesn’t belong in business

Robert Oppenheimer, working at Los Alamos during the development of the atomic bomb, was asked once why he’d done it.

“If an experiment is sweet, you go ahead and do it”, he said.

A lot of chatter in business today — and by business I include government and the third sector — turns on the magical properties of what’s known as “big data”.

There’s a presumption that spending millions massaging, sifting, analysing and reporting on masses of data, both internal and external, will somehow reveal the secrets needed to take the organization forward.

Been in your data centre lately? You’ve had reams of data for years. Why is it that suddenly you’re going to make use of it?

Oppenheimer, of course, didn’t have to bear the consequences of his experiment. He could play the disinterested scientist, only going after the facts, and leaving the moralizing and judgement to others.

Later, when he saw that he did, in fact, like the rest of us, have to bear the consequences, he changed his mind.

For an enterprise, it’s not necessarily so easy. The complete world system was sluggish enough and diverse enough that Oppenheimer could change his mind and survive doing so. Enterprises — even governments — don’t have that kind of staying power.

Let’s be clear: we’ve systematically used information technology to limit decision making over the past thirty plus years.

People still have responsibilities on paper, but the reality of delegation of financial authority, sign-offs required, and the like mean that few actually can exercise much of it. Moreover, by removing all the slack from budgets, and requiring that absolutely every initiative “work out”, we’ve put a high premium on not making mistakes, and not backing away from approved courses of action.

In other words, we’ve created an environment (and systematically culled each and every iconoclast who’d press back against it) where almost no one will willingly stick their neck out and make a decision on their own.

Pray tell, therefore, why suddenly making information available will somehow unleash waves of innovation, responses to markets, and seizing of opportunities?

How many middle and senior managers are willing to stand up and say “I don’t know what’s going on” when asked? For that is the price tag of unleashing big data on the organization and demanding it be used for generating results: you won’t know everything that’s going on.

Safe-to-fail experimentation and control from above are mutually exclusive. Yet it’s only in safe-to-fail experimentation that the information exposed through analysing all that data gets tested, and innovation to put it to work occurs.

In other words, to really get value from masses of information, you have to unlock your organization. Seriously change it — and its management expectations and methods.

Here’s a paradox to reflect upon: in many ways the ancestor of our organizations, the military, is more capable of handling these changes than the average private sector enterprise is.

That role-based structure and fixed reporting lines inherent in armies, navies and air forces turns out to be surprisingly flexible, precisely because more senior officers know they can’t direct the troops in real time. (Nor should they.) Colonels do not sign off on every little issue from the stores for corporals. Compare that to Senior Vice-Presidents signing off on whether or not a clerk gets a headset for their telephone (and yes, that’s the norm these days).

You can’t use information if people aren’t free to put it to work. Thumbscrew tight budgets, top-level control, and “no surprises, no failures” all work against that.

If you want value from big masses of data, you’d better start by rethinking how your organization is managed.

Posted in Information | Tagged , , , | Leave a comment

If the IT you have didn’t exist, what would you put in its place?

Here’s a thought experiment for you. Suppose you didn’t have any information technology in your workplace? What would you choose to do, with no pre-existing investments getting in the way?

Let’s presume, for a moment, that you’re an office-centred business. (Plant floor or resource extraction environments, to choose but two, are office-centred with field operations, so choosing the office fits just about everyone.)

Well, these days, you’d start with individuals. What tools do they need to be able to communicate, share, handle workflows, etc.?

In today’s world, you’d look for technologies that have as much security built in as possible. So you might well choose BlackBerry 10 devices for their phones (excellent security features coupled with best battery life while leaving them all turned on, including all-day-long VPN), and then decide whether to go with tablets, laptops or desktops. Those phones, incidentally, replace phones on the desk, so you’d only put speakerphones in meeting rooms. Your company switchboard forwards calls directly to handsets.

For, in 2013, more people text message, instant message, email, or the like than call anyway. Meanwhile the large purchase of cellular service allows for a custom contract to be negotiated.

The office is fully enabled with wireless networking. Most people use tablets or ultra light weight laptops, so that they can move from place to place as needed. For people in clerical roles, the desktop may still be used.

But those devices are all chosen for longevity, security and ease of use. Gone are the days where one standard machine was imposed, not good enough for the few who needed power and overkill for many others.

That’s because you’ve read the studies, and know a mixed environment actually doesn’t cost more, any longer, to maintain and support.

All your applications would probably be drawn from the cloud. You’d certainly put core services like email there. You’d probably put a lot of your data storage there, too.

Better to pay for hefty network capability than to build a data centre — or to manage one. Since the capacity on the network is needed even if you outsource, you might as well go whole hog.

Only those applications that can’t be bought in the cloud would end up in a managed service facility of some sort — and there, you’d want to implement them as a private cloud in any event. Fully virtualized, fully responsive to load changes.

But mostly, what you’d be doing is removing functions left, right and centre, that built up over the years and aren’t needed now.

You might be surprised, in fact, of how little you’d actually put in place, relative to what others have.

Do you think this little thought experiment is a pipe-dream? Well, look at a start up company. None of them go hog wild on technology. Just about all of them follow this model.

That’s not just because they’re small. It’s because they can’t use all the specialized functions without whole departments of people there to drive the work.

Instead, they expect individuals (managers or staff) to take responsibility and to act responsibly. Quick discussions keep everyone synchronized, and “sign off” takes place so that procurement, for instance, can happen.

So, having concluded our little experiment, let me ask you: what’s stopping you from simplifying your life?

Odds are, depreciation on an install base isn’t the biggest reason. It’s a lack of imagination — and years of reducing trust in individuals.

IT made it possible for organizations to “have control”. Along the way, many used it to remove authority.

You couldn’t run what you’ve got now without it. But your next competitor can.

Posted in Asset Portfolios | Tagged , , , , | Leave a comment

Organizations are conservative

You’ve got all these people. So you organize them, right?

That was really useful back when communications around the office moved at the pace of a handwritten note or a typed carbon copy, coupled with an occasional person-to-person telephone call.

Organizations are a way to institutionalize a specific order. When they correspond to what needs to be done — and how it ought to be done — they are quite effective.

It’s why Jon Husband talks about his notion of Wirearchy (or Organization for this century) as a coupling of hierarchy and peer-to-peer relationships. Hierarchy remains to conserve some order; peer-to-peer opens up possibilities in a less ordered way.

What that also suggests is that the temptation to tie everyone down into an organizational structure — Person X is a member of Department A, which reports up through P — is highly inappropriate to give into for some kinds of work.

Some groups should be self-organizing. Work in the Cynefin framework‘s domain of complicated order is already conserving enough (through the agreement of experts); adding additional power via hierarchical relationships and structure may imbalance the enterprise. Would it be better to think differently about a classic team of experts — say enterprise architects — and scatter throughout the enterprise but have them meet to accomplish architectural results rather than that an architecture group be formed?

Husband’s Wirearchy suggests that would be true. Good practice doesn’t need to be tied to organizational structure.

It’s hard for managers brought up in a world where every position has a position description that in turn becomes the framework for a performance evaluation, and every employee fits into a neat little budget centre and organizational box, to envision seas of loosely-coupled staff forming into teams, carrying things out, them dissolving back into a pool again.

But why not? Isn’t this how Hollywood and its peers make movies and television shows? You’re a camera person, you’re hired to be on this production, you show up and give your best contribution under direction and with ideas from peers, then off you go maybe never again to work with that cluster of people.

The typical IT organization today in a multi-billion dollar corporation has several hundred project-oriented people working for it — every one of which is unavailable to most projects because of organizational structure. Think about that, and wonder if perhaps some of our problems in translating change into productivity stem from such nonsense.

Instead of lock-step structure (manager = budget centre + headcount + purpose) you might have money and people flowing toward purposes to be achieved, then coalescing in new forms.

Now if your goal is to get payroll out, or pay bills, or process incoming monies, you probably still want a high and simple order — the sort of thing the classic hierarchical organization provides.

But if your goal is to get things done in a changing world, perhaps you need something different. Something that looks less like the past thinking, and more like the future.

Before, you know, someone beats you to it, and has your enterprise for lunch.

Posted in Enterprise Architecture, Human Resources, Management & Leadership | Tagged , , , | Leave a comment