Panelists

	Roger Burlton	President & Managing Partner, Process Renewal Group Founder, BPTrends Associates
	Steve Erlank	Strategic Consultant, Faculty Training Institute
	Ronald G. Ross	Co-Founder & Principal, Business Rule Solutions, LLC Executive Editor, BRCommunity.com
	John A. Zachman	Chief Executive Officer, Zachman International

Moderator

Roger Tregear

Consulting Director, Leonardo Consulting

Statements

1. 'Building business capability' is about people, not artificial constructs like strategy, rules, processes, architectures, and requirements.


2. In five years, the job title 'Business Analyst' will no longer exist.


3. Agile was created by developers to cut out Project Managers and Business Analysts.


4. In the next fifteen years there will be digital programs capable of replacing the skillsets that business analysts now have....


5. There will be a larger supply of business analysts than demand in the market in the next five years.


6. Business Process Management, Business Rules & Decision Management, and Business Architecture should never be based in an IT department.


7. At a future BBC event the delegates will scoff at the naïvety and simplicity of what we today think of as 'sophisticated and complex' models.


8. We've been talking IT versus business....


9. We will see a continued movement towards decentralizing IT into business....


10. In the future the users will be the developers.

Welcome & Introductions

Thank you all for joining us for the 'guru' session.  My name is Roger Tregear and, as you might have just worked out, I come from a land down-under.

We've been running the "Opinion of Gurus" session at conferences in Sydney for the last five years, usually with some of these gurus.  And we've always had a problem knowing what to call this session — Is it an opinion of gurus?  Perhaps it's an architecture of gurus? … a model of gurus?  … a repository of gurus?  … a capability of gurus?  It was suggested at one time that there probably should be an invoice of gurus.  But we stuck with opinion of gurus.  We're happy to hear your suggestions about that for future years.

Let me briefly introduce the gurus, not that they particularly need any introduction to this audience, at this end of the conference.

Roger Burlton is Co-founder of BPTrends Associates and President of Process Renewal Group.

Steve Erlank has been, and is, all sorts of things:  business executive, entrepreneur, past president of the IIBA in South Africa.

Ron Ross is Co-founder of Business Rule Solutions, certainly needing no introduction here.

And John Zachman is … well, he's John Zachman.  <laughter>  <applause>

It's a privilege to have these gurus here with us today.  We will have some fun, but we will also address some pretty important issues.  We're going to do that in a couple of ways.  Our gurus have these signs:

    

Now you understand immediately what they're for, but I'll explain it in detail for the gurus.  (They always struggle with this.)

We'll put a statement up on the screen, and if they disagree with it then they're going to hold this one up.                 If they agree then they're going to hold this one up.

Now, you know what 'red' and 'green' mean, but there's a cheat sheet on the back for them.  See:  It says 'AGREE' and this says 'DISAGREE'.  Okay?

Now, Ron will immediately say, "Hang on!  What does a 'thumbs down' in green mean?"  Go on, Ron, say it.  You always do!  <chuckles>

Okay.  So this is how it will work.  I'll be putting up statements on the screen.  Many of you have seen these statements already because we did some surveys — involved all sorts of people.  From those suggestions, along with ones we've used before, we came up with five statements we will use in this hour that we're together.

At two spots during our time we're going to invite you to present statements to the gurus — any statements you like (provided we don't need to get legal advice as a result of what you say). 

The gurus will vote to agree or disagree with each of the statements and then have a rousing sharing of their opinions.

So, that's the plan.

Ron's got a question already.  And a microphone. 

  Is there a time limit on each of the answers?

  I think you just reached yours; thank you very much.

  I know why he's asking the question.  Ron, I completely concur.

  And we're all looking at you, John. <laughter>

There's a reason we make this the last session — it's supposed to go for an hour, but they will all complain about each other talking too long, and they'll take a long time to complain.  So we could still be here at two o'clock.

  We'll still be disagreeing when everyone's gone.

  That's right. 

Okay.  Let's get on with it.  Here's the first statement.  I'm going to put it up and then our gurus are going to respond.  And then we'll have a chat about those responses.

'Building business capability' is about people, not artificial constructs like strategy, rules, processes, architectures, and requirements.

Agree or disagree?  Gentlemen?? You all disagree?  What about the people?  Roger, tell us.  You've got a microphone in your hand.

  First, I've got a question.  If I had a 'thumbs up' in Australia, is that a thumbs down in North America?

  Oh, boy.  Gurus, huh?  The real gurus couldn't turn up, so we got these guys.  <laughter> <applause>

  I think it's becoming more and more about people, but it's not only about people.  I think that's the question.  I just wish I could put the sign sideways like that. 

There are going to be abstract constructs, as opposed to artificial constructs (strategy, rules, processes, architectures, requirements), otherwise people won't know what to do.  So I really do think that it's not only about people.  It is about people, for sure, but all the other things are still going to be there, for a long time to come.

  Steve?

  For those of you who don't know, I'm the younger part of the panel.  I'm here to represent Generation-Z.  In general I have to take up a contrarian position, but in this case I won't. 

And, by the way, Roger, if you do it that way [thumb pointing sideways] it means "I'm out of here."

But, seriously, people obviously do all the work.  Organizations are comprised of large numbers of people and you need to get alignment, otherwise you get no progress.  You have to have strategy, rules, processes, architectures, etc. in order for people to function coherently.  I think these are the enablers of activity in organizations.

  Okay, thanks.  Ron?

  What we need to be able to do is to engineer solutions (I borrowed that word from John) because this is a problem of great complexity (I borrowed that word from John).  And so what you need are the right tools in order to engineer the solution.  I don't want to just pull somebody off the street, without the skills — the tools, the techniques — to do the job. 

  It is possible, though, for us to get tunnel vision sometimes and think that it's all about models and boxes and arrows and rules and architectural diagrams.  And then you think, "Where are the people?"

  So is it allowed for the moderator to defend the question?

  I'm the one standing here.

  I'm the one with the microphone.  <laughter>

  I think we should put that up as a question and ask the gurus whether or not we should do that.

  Should we do what?  Should you take control?  No, the answer is, "No."

  Actually, I have about two hours on the answer to this question.

  Thanks, John.  That's very good of you.  Let's move on. <laughter>

  I was tempted to just agree with Roger.  He had kinda the right answer. 

But I'm going to resist that temptation and say that "building business capability" is about inventories; it's about processes; it's about locations; it's about people; it's about time; it's about motivation, objectives, strategies.  And, for each of those, it's about concepts and it's about logic and it's about physics and it's about some other things, which I won't take the time to elaborate on.  But it's about all of the above.  Okay?  So, it's not about one thing.

And I agree with Ron, who agrees with me, that we're talking about extreme complexity here.  So, it's not just one thing — it's all of the above.

  Okay, thanks for that.  "All of the above" is a good way to sum it up.

We also polled you, the audience — and others who aren't with us — and we asked what you thought about this.  (You might have participated in that survey — some 250-300 people did.)  There was a general 40/60 split, which was interesting.

AGREE:   42%     DISAGREE:   58%

Okay, let's move on and do another one.  Here is the statement:

In five years, the job title 'Business Analyst' will no longer exist.

Okay, everyone disagrees?  No, you agree with this, Steve?  So you say all of these people out here won't have a job in five years?

  Well, this is a hard question for me to answer because, in my company, we've trained about eight-thousand business analysts — my whole work for the past 20 years has been business analysis.  So it's really hard to say this, but I agree that the job of business analyst won't be around in the future. 

And here's why — two words:  disintermediation and identity.

Too many business analysts out there are intermediaries — they are the conduit between business and technology.  And we know that, with technological change — with changes in processes, with changes in activities — disintermediation occurs and intermediaries are excluded from that process.  For those of you into some of the agile sessions you'll realize that people are talking about this — that technology can talk directly to business now if they have a common language.  So that's the first thing:  disintermediation.

The second thing is identity.  Unfortunately what seems to be happening is that, as business analysts are grappling for identity, they are trying to be all things to all people.  And there's a real risk in that — that you make yourself a generalist and you lose the identity of the word 'business analyst'.

There are just two solutions to this:  the two words are 'evolution' and 'specialization'. 

Quite a few of the speakers have talked about the evolution of the old order-taking business analyst into the new kind of business analyst, one offering value (etc.).  I think the IIBA has a very extreme role in this, together with all the members and all the business analysts out there, to redefine the new identity of the business analyst going forward.  If the business analyst role, as we know it today, fails to evolve there'll be no need for business analysis in the future. 

That's a hard call to make, but it's pretty much the way it might go.

  So, it's not just the title, Steve, but the work of business analysis is gone?

  We'll always have analysis and there'll always be business.  But if we're borrowing all our disciplines and all our ideas from other disciplines it's those disciplines that will remain strong.  Specialization will say, "Maybe I'm a change manager.  Maybe I'm a process expert.  Maybe I'm an academic."  Whatever the specialty is.  And that loses the focus of the more general term.

  So, Ron, are all the business analysts going to be process experts?  Is that what you're about to agree with?

  Well, it wasn't quite the word I was going to use.

  I don't think Ron's going to say that.

  Yes, there's this matter of rules and semantics. 

But, be that as it may, I disagree for the simple reason that the question says "five years."  (I actually paid attention to what it says.)  And I know, in our industry, it takes more than five years for any major change to happen. 

It certainly has taken longer than that for business rules to now be an established part of the discussion space that we have here at the conference.  The decision modeling people will see that it takes much longer than they thought in order to take hold within the space. 

Things in our industry just take longer than five years.  It's more of a decade-long journey.

But I want to disagree with Steve on one point, which is a very important point.  He brings up disintermediation, and I absolutely agree that the future holds disintermediation.  But I think it's IT that will get disintermediated.  I think IT will be thrown out of the loop, and what we now think of as 'business analyst' will be the ones having the conversations — in structured English, with smartphones and laptops — in order to disambiguate the business and the business solution, in discussion with business people.  I think it's IT whose days are numbered.

  Anyone from IT here?  Sorry.  You need to leave immediately — get to work on your resume. 

  They're gone already.  <laughter>

  Oh, sorry, I was behind the curve on that one.

  There was an interesting day the week before last which was the day that Marty McFly ended up in the future — the actual day on the machine in the car.  And all the stuff in there was pretty much still not true.  And so I think the same is the case with this. 

So I would agree with Ron (even though it kills me to do that) but it takes a long time for these kinds of changes to happen.

But I do think probably what's going to happen here is the role of business analyst is going to broaden even more — so I disagree with Steve on that.  I think it's going to become business architects, where you start to define 'what' needs to be done, as opposed to 'how' things need to be done.  Based upon that, the roles should get broader.

The good news about that for IIBA is that they don't need to change their logo.  <laughter>

  So is that not a business analyst mutating into a business architect?  Like 'growing up'?

  We're not going to talk about mutant business analysts in this conference.

  Okay.  Let's see what the survey said….

  I've got an hour-and-half on this one, too. 

  That's why I was trying to move on.

  I would say that somebody has to do actual work.  And I really don't care what you call that person — whether you're going to call that person a 'business analyst' or something else. 

I like what Steve is saying about the degree of specialization.  We don't have very good specialization in the enterprise engineering and design domain these days.  We tend to think there's going to be one chief enterprise architect who's going to design the whole enterprise. 

But I'm going to explain that there's not one chief architect that designs the Boeing-747.  There are manufacturing engineers, aeronautical engineers, hydraulic engineers, pneumatic engineers — one person doesn't know everything.  You can't expect one person to engineer the entire object. 

And an enterprise, I would argue, is an order of magnitude (or two!) greater in complexity than a Boeing-747. 

So, we don't see the level of specialization today in doing enterprise engineering and design kinds of things — because we don't do engineering and design of enterprises.  We build and run systems, typically.  So therefore, we're manufacturing people — we're not really engineering people. 

But, once again, somebody has to do actual work.  In fact, some of you guys have heard me argue that the responsibility for enterprise architecture probably lies in the general management domain.  In fact, if the CEOs of the world understood enterprise architecture and could orchestrate their own variations and analytical structures themselves it would probably be better.  It would disintermediate a whole lot of things.  But the stress levels are really high in the general management domain. 

Some of them may, in fact, do that kind of actual work.  But I would submit to you that probably not all of them are going to do that kind of actual work.  So somebody has to, and if the title of that happens to be 'business analyst' that's okay. 

A friend of mine, Dan Appleton, argues that who we're describing here is the staff person to whom the general manager turns and says, "Go check this out and see what it's about.  Tell me whether we should do it or not."  Maybe that's a business analyst — I don't know.  Or if the general manager can do it then maybe he or she may do it themself.

  John, what do you mean by 'engineering people'?  Is that genetic engineering? <laughter>

  You know, the fact of the matter is a lot of money is being spent right now by not only the U.S. government but many governments on genetic engineering of people.  And if you want to know my opinion about it, well, …

 And we'll take that question offline.  Ron, what have you done to me?

Okay.  What did the survey say on this?

AGREE:   18%     DISAGREE:   82%

It said that most people disagreed with that entirely — which presumably means that most of the respondents were business analysts. <laughter>

Okay.  One more statement before we'll ask you for your statements.  We won't have much time for that so start thinking of the very best statement you've got.

Here's the last statement before we go to yours.

Agile was created by developers to cut out Project Managers and Business Analysts.

That seems pretty straightforward.  What do you all think?  Votes? Kick us off again, Steve.  This is your caper.

  All right.  Now I have to reveal my true identity.  Inside this beating heart of a business analyst lies a developer.  That's where I started so I must tell you a little secret, "Yes, this is true." 

We found, back in the 80s, that (in fact) systems analysts and project managers were just getting in the way of the creation of beautiful software.  So we invented this agile movement, and everyone got on board.  And then we invented scrum, and what scrum does is get rid of those useless users as well and replaces everyone with the one individual called a 'product owner', who's a surrogate for the entire business and all the customers out there.  This is about efficiency — about writing good lean software. 

So, I'd have to say that the secret is now out and we cannot hide from it any more.

  Agile is the new black, isn't it?  I've recently heard of 'agile management', of 'agile processes', of 'agile rules', of 'agile development' — I mean it's the adjective of the year, yes? 

  I would contend that 'agile' was created by business analysts to cut out developers and project managers <laughter>  — to stop the project managers from messing things up just because they've got a budget and a schedule to meet.

  And they're trying to build stuff — got to stop building stuff!

  And cut the developers out because they just slow things down.  We've got the answer already; how come they're taking two years to build it?

  I was wondering whether John or Ron had an answer to that, but we're not going to find out.

What did the survey say?

AGREE:   15%     DISAGREE:   85%

It said that, again, most people disagreed with that, confirming my …

  The crowd is calling for our answers.

  Are these Ron's groupies?  "We want Ron!  We want Ron!!"  All right, Ron, you've got 30 seconds.

  Remember where you are….

  30 seconds, Ron.

  Be agile, Ron.

  'Agile' was also created to cut out designers and business architects and business rule people and business process people and a whole lot of people. 

However, there's a semantic problem here when you say 'agile'.  And I wish you'd given some definitions for some of these terms; it would help the discussion.  Because there is such a thing as 'agile analysis' — and I'll exclude that completely from my answer since I would love to see more agile analysis.  I think here at the conference next year you will see more agile analysis sessions and activity. 

But if we're talking about 'agile programming', agile programming is the last gasp of the procedural paradigm to build systems.  We'll move on to some better (much better) architectural means to produce and configure systems in the near future.

  Is that 'agile architecture', Ron? <laughter>

  3 seconds, John.

  I've got 3 seconds.  I really agree with Steve on this one.  'Agile' was designed to produce running code.  The other thing I agree with is the scrum idea.  If any of you have ever seen a rugby game the question turns out to be, "What is going on in the scrum?"

  What happens in the scrum stays in the scrum. 

  With an Australian on the stage we don't talk about rugby right now.  Or a South African.

  Here's a clue:  What goes on in the scrum, nobody knows … except if Australia or New Zealand are playing, it's probably illegal.  <laughter>

  I was in New Zealand not long ago, speaking to some experts in rugby, and they said that the purpose of the scrum is not what you think.  It's actually to tie up all the big players so the ball can come out to the small, agile players, who run around the sides … which doesn't seem like what the people who use 'scrum' in agile really intend to mean.

  So, actually then the scrum is there to get rid of the project managers and the business analysts?

  To create gridlock so the smaller, agile people can score goals.

  So now we've got a Texan and a Canadian telling us how to play rugby. <laughter>

  Roger, I hope you're back next year.

  Watch out — the Canadians have big hockey sticks!

  Texans have guns.  <laughter>

  Okay, you win.  Now that would be a scrum.

What questions do you (the audience) have for our gurus?  Just stand up in your place and wave frantically, waving hundred dollar notes.  That will help you get the microphone.

We would prefer a statement that these guys can agree and disagree with, and then we'll talk about it.  Can you do that?

Audience:  Sure.  Here's my statement.

In the next fifteen years there will be digital programs capable of replacing the skillsets that business analysts now have, furthering the trend of automation and elimination of jobs.

So you're saying we won't have business analysts — "We'll have an app for that." Roger, you're the odd man out.  Where have I heard that before?

  Happens a lot.

  Every conference.

  I am going to agree with that statement.  For example, fifteen years ago who would have thought that today we'd have some of the things we talked about?  It's quite different now in terms of our jobs.  So I really do think we'll be seeing a large degree of that. 

But, again, I don't think that this means the end of business analysis or the end of business analysts.  I just think the role becomes even more important from a business management and a business direction point of view, as opposed to just, "Oh, I'd like to automate this — can you help me?" 

  Okay.  John?

  I don't think that the humans are going to go away … because it's a specialization issue.  Humans are good at some things and machines are good at different things. 

Yes, we're going to see a lot of creativity in the hardware.  We're going to have cognitive kinds of computing.  But it is all still based on facts — if somebody doesn't have the facts, and have the order of those facts in an ontological structure, it doesn't matter how cognitive the machine is, it's not going to be flexible because you can't achieve flexibility to restructure things dynamically unless you separate the independent variables.  There's going to have to be an ontological structure. 

I've been talking about this for forty years and I'm not too sure that I'm going to keep talking about it.  Maybe not for another forty!  But that's going to be the bottleneck if they want to do something.

And here's a second issue.  A lot of money is being invested these days in modifying and enhancing human beings.  But they're ignoring some of the unintended side-effects.  I don't think the humans are going to be eliminated from the picture any time too soon, okay?  They're still going to be there.  Somebody has to make the decisions; somebody has to have the value judgments to decide what's right and wrong.  People — human beings — have that capability.

It's an interesting issue we're having right now.  We've raised a few generations of people who we haven't trained very well to make the decisions about what's right and what's wrong.  And we're seeing the effects of this in unintended side-effects in the societies of today. 

Hopefully there's going to be a turn-around on this issue.  I don't think the human is ever going to be out of the picture because they're the ones who can make those kinds of judgments.

  That's good news for all of us.

Next question?

Audience:  My statement is this. 

There will be a larger supply of business analysts than demand in the market in the next five years.

Okay — "supply will exceed demand" in terms of business analysts.  So, all of the people on this side of the room (waves hand) will be unemployed.  Panelists, what do you think? So, you agree, Steve?

  Yes, I think that we're seeing this at the moment.  I think there are organizations that are desperately trying to hire business analysts and those same organizations are also laying off business analysts. 

So I think this lies in the semantics of what is a 'business analyst'?  (Hopefully Ron will agree with me?)  I think organizations are looking for something new, different from business analysts — something of more value (etc.). 

I think those business analysts who are just 'order takers' (which, in fact, is the training and experience of many business analysts) are finding there's an over-supply.  We're seeing that in India; we're seeing that in South Africa; we're seeing that in the U.S. as well.  So, yes, I would agree that there's an over-supply of business analysts, depending on what you mean by 'business analyst'.  We need Business Analysts with a capital 'B', capital 'A'.

  There's going to be an increasing need, in the years to come, for people who can communicate.  That includes whether you're speaking with people in the business, as a change agent, or whether you're speaking with machines, in a conversation to describe the semantics and configuration of the business.

It's the people who have the superior communication skills who will be in increasing demand.  That's not going away.  They have the change-agent skills.  And that's mostly you guys.  It's not the IT people.

  I agree with Ron.  But that just puts every business analyst at the same competency level.  I think there will be some business analysts who have the higher competency and will be desperately needed.  But some of the other ones (those doing very, very low-level work) … some of that work might go away.

  The answer to this from my perspective is somewhat the same as for the previous question.  Somebody has to do actual work.  And I'm not too sure I know what the title of that person happens to be.  'Business analyst' probably is not a bad title. 

But I would submit to you that the business analysts of the future are going to have to be the people who will diagnose the enterprise problems.  We don't diagnose problems now — we identify pain.  But somebody's got to diagnose the problem, and I believe the business analyst may be that person (maybe by some other title). 

As I said earlier, you cannot diagnose the problem without an ontological structure.  There's no way to do it — you can't get there from here.  So, fundamentally, someone has to sit down and do actual work … populate the knowledgebase of the object that you're trying to fix.  You have to know how that object works. 

If you want to diagnose the problem you're going to need to know how the enterprise works — and I'd submit to you that if you can't show me a set of single-variable primitive models you don't know how the enterprise works.  So, this presumes that you're going to have a set of descriptive representations called a 'model' (a primitive model).  'Business analyst' may be the title of the person that's going to do that.

  We'll come back and do some more questions later.  Let's come back to our set of statements here.  Before we finish we'll have another round with the audience. 

Here's the next statement.

Business Process Management, Business Rules & Decision Management, and Business Architecture should never be based in an IT department.

Gentlemen, agree?  … disagree? So, these should never, ever be based in the IT department?

  No, it doesn't say "never, ever."

  Okay, they should "never" be based….  I'm not sure I know what the difference is.  Aren't most of these already in IT departments?  Isn't that where they came from?

  Unfortunately, IT departments still control the money.  And as long as you control the money, things are going to start where the money is.  So that's my main reason for disagreeing with the statement.  You've got to start where there is support for getting started.  It's not that you don't immediately try to work your way out of it — toward the business — but, you know, you have to be pragmatic about it.

  But you see some problems if it's seen to be a creature of the IT department?

  Well, of course.  Because none of those things really are about (or shouldn't be about) IT per se. 

  I think one of the strange things about this type of question is that we call it an "IT department" but we call the person in charge of it the "CIO" (Chief Information Officer).  And some of them actually do have a perspective far beyond technology — they can be quite brilliant and visionary.  I've seen a lot of organizations where it's the best place to put it because you've got the right vision from that organization.  So, that's why I couldn't say "never, ever" for this one.

  John, your comment?

  I would observe that IT may not be the best place for these issues to reside, but somebody's got to do it.  If general management doesn't 'get it' — if they don't understand the issues — IT is probably not a bad place for it to be.  But at some point in time it has to evolve to a general management responsibility.

  And at some point IT needs to know a lot about processes and rules and decisions and architecture because they've got to build stuff — they've got to do actual work (as you say).  And if the business doesn't understand these things then they have to.

Is that how it starts?  Steve?

  I think this is a process of evolution.  I think that organizations are changing.  If your organization is fairly traditional this debate will continue.  But I think there are new forms of organization — things are dispersing; things are being out-sourced; things are being in-sourced. 

So, I'd agree with Roger that the problem is the word 'never'.  We're not allowed to use this phrase up here but I'm going to use it anyway:  "It depends."  I think that mature organizations will base any capability in the organization structure where it best fits — whether that's IT, with great people with the business vision, or whether it's in business, with people with an understanding of technology, that's where these things need to be located.  I think mature organizations will find that way and structure their organizations accordingly.

  How many people in the room doing this sort of work reside organizationally in an IT department or something like that?

Okay.  That's where all the money is.  Did you get all that?

So, what did the survey say about this?

AGREE:   59%     DISAGREE:   41%

A kind of 60/40 split — governments change on slimmer margins than that.  This is certainly not as diverse as the previous statements.

Let's do one more.

At a future BBC event the delegates will scoff at the naïvety and simplicity of what we today think of as 'sophisticated and complex' models.  Cognitive business architectures will have replaced our passive models.

Gentlemen? Ron, you've got a microphone in your hand.  What did you have?  You agreed, yes?

  Have you looked at your kids talking to their smartphones lately? … having conversations about where pizza places are (and so on). 

The ability of 'smart' machines to have dialogs with us in structured English is coming … absolutely coming.  And that will enable us to have conversations with machines about what our business rules, our business policies, are — what our business processes should be.  And we will be able to configure things in ways that are very difficult to even imagine today. 

I'm absolutely positive that that's going to happen in the next five to ten years, and it's going to be a major revolution in the way things get built.  This has significant implications for existing roles and responsibilities within the organization. 

So, it's coming.  Do not doubt my word.  Major change is coming.

  So, John, do you think that there's a system in the future that could go through all of the documentation that exists for an organization — some sort of cognitive technology — and derive from that the architecture?

  Well, you've changed the question, Roger.  But I don't believe that a machine is going to ever be a substitute for people — I don't think that's going to happen because of the value issues, the judgments about right-and-wrong kinds of things.

In terms of the naïvety, in the future will this be looked upon as naïve?  Yes, I think that's the case because enterprises today … we don't create complex enterprises.  We have log-cabin kinds of enterprises — pretty simple.  They never were engineered; they were never designed.  They happened, iteratively and incrementally, over time.  It's like a whole bunch of log cabins, where it gets complicated because you don't know what's in every log cabin.  That's the fundamental problem.  If you could engineer the enterprise, I will tell you, you could build hundred-story enterprises rather than log-cabin enterprises. 

So, yes, I think we'll look back years from now and say, "That was pretty primitive!" because there was no engineering going on in the enterprise domain.

The other part of the question talked about 'cognitive business architecture' replacing passive models.  Somebody is going to have to define the knowledgebase that's going to be in there.  The model is only dynamic because the passive model you put in it is engineered with the separation of independent variables so that things can be dynamically changed.  That's what makes it dynamic.  Somebody is going to have to populate it; the machine is not going to replace the people.

So, I agree with the first part of the statement — we don't have complex enterprises (they're not engineered).  We write code, write some more code — we're agile.  We're basically building things little by little by little.  It's never integrated, never engineered. 

  How many of you believe that your organizations are not complex?

How many of you believe that your organizations are complex?

Okay, John, just a little clarification.  The complexity that a lot of people see is because the organizations haven't been engineered properly.  So, I think everybody is actually on the same page, but it's a little misleading when you say it that way.

  Nobody knows what's in all the log cabins.  That's fundamental.

  Much better.  Much better.  I knew he could do better.

  Just recently I was reading a paper by Tom Davenport.  He referred to a word that he starts to see being used — "cognitizing."  Not "digitizing."  We're going to cognitize the world. 

  I'd like to make one comment on this.  I actually see business architecture as part of strategy.  It's not just a reflection of strategy. 

And I separate 'strategic intent' (goals, mission, vision, etc. — all the places where you want to go).  I don't see how any machine is going to automatically take some vague statement ("We'll double our business in the next three years." and "Markets are growing at one-percent per year.") and turn that into an architecture. 

People still need to do the determination of what that strategy should be and reflect that in the architecture.  I don't see machines doing that.  I agree with John.

  It's a question of how much art and how much science is there.  IBM Watson could go ahead and read every available thing on strategic planning and everyone's strategies and everything about markets all over the world, and infer things that the human beings couldn't. 

  There are two aspects to this question that I'd like to touch on. 

One is a theme that's starting to emerge at the conference.  For generations, for millennia, humankind has endeavored to simplify things.  I think what I'd like to see coming out of this conference is the move toward more design-thinking, where we take the very complex things that we do and we embed them in very simple interfaces, on a smartphone — simple interfaces like on an iPod.  Human endeavor (and perhaps our job as well) is about taking the complex and making it simple to the average user.

The second aspect of that is that the whole purpose of modeling (and I think John's architecture models are an extreme case in point of this) is to take the complex and render it down into something simple.  It's a complex world.  We have to model it.  The whole purpose of doing that is the simplification of, and the structuring of, things.  That's where the principle of architecture comes in.  If we, in this room, are taking the complex and making it more complex and less understandable we're not doing our jobs.

Maybe that's the underlying theme — to say, "We all have to make everything as simple as possible and to make a complex world more understandable and more accessible to everyone out there."

  In my experience there are two sides to the word 'simple':  One of them is 'naïve' and the other one is 'elegant'.  You can design something to be elegant, and it works incredibly well and it's simple.  Or you can make something simple and it's just stupid.  So, I think we have to be careful what we mean by 'simple'.

  The reason IBM Watson does so well in medical literature and in diagnosing problems is because it has access to three things. 

It has access to a highly-standardized vocabulary in the medical community that people use consistently.  Ask yourselves how many organizations have standard vocabulary they use consistently?  None. 

The second thing is that it has access to vast troves of well-written research papers and documentation that it can read, digest, organize semantically, and evaluate.  Most businesses have no such documentation — there is no such clear expression of what the business is about.

The third thing is vast troves of data, of cases (patient cases), that it can train itself to improve on.  You could argue that businesses do have troves of data that you could evaluate, if you had the other two things in order for cognitive machines to make some sense out of it.

But, having said all of that, IBM Watson is not the future.

The major ingredient that approaches, methodologies, techniques today miss is intellectual capital.  Intellectual capital is the most important asset of everything that we have.  And we are just beginning to learn how to capture, express, disambiguate that.  That's where you're going to see the major innovation, and machines will have a major role to play in that area.

  Okay, let's see what the survey had to say.

AGREE:   56%     DISAGREE:   44%

Again, we have a 60/40-type split, but certainly on the side of more complexity, more sophistication — less naïvety in our future models.

Okay.  We've got ten minutes left for questions (statements) from the audience.

We have one here, up front. 

Audience:  Here's my statement about where the business analyst world is headed.

We've been talking IT versus business.  In the not too distant future, the business world will recognize that a new pillar will emerge within business where these different roles — whether it's business analysis, architecture — will gravitate to.  This will be a whole new business pillar within the organization, one that will sit between the two.  It won't then be an "us vs. them" any more.  Both sides will come together in that pillar.

Okay.  We have: Further comment, gentlemen?  No?

  The next question was over here.

Audience:  Hello!  Thank you for this really entertaining and informative set of guru opinions.  I appreciate everybody's time.

My question comes from my history with my company over the past three years.  We started off as a centralized business analyst group, and we decentralized shortly after that so business could move to a more technical perspective — to execute and gain credibility where we had suffered before.  In that reorganization we ended up decentralizing IT pretty extensively.  We went from an architecture and engineering group of about 140, down to about 40.  The other 100 people went back into the business.

So, my statement is this. 

We will see a continued movement towards decentralizing IT into business:  converting the business analyst into more of a technical product owner, who then works with business product owners to go ahead and capture the requirements, and then works a little bit with IT and the enterprise architecture group to make sure we're moving toward that enterprise context and strategy.

Gurus, what do you think?

  I think that brings out a very good point.  The issue here is that this is not new. 

People have centralized, decentralized, centralized, decentralized … every five years, when Accenture comes in and says, "Oh my gosh, look at all the redundancy; you'd better centralize."  And then says, "Oh my gosh, you're not close to the customer.  You'd better decentralize."  And that keeps you going for a long period of time.

The challenge here is:  If you decentralize too much who is going to determine the need for cross-functional solutions?  Who's going to fund the ERP that goes across all those different departments?  How are you going to budget your resources for change when everyone is just pitching their pet projects, some of which are not really necessary for the organization to be successful?

So, if you're going to go that way you still have to have a high degree of centralized planning and prioritization and resource allocation, to make sure the right things are getting done. 

  John?

  I think that question was somewhat similar to the previous statement. 

I would observe that we are all the enterprise.  As soon as I hear "we … IT" and "you … the business" (or "we … the business" and "you … IT") that's a recipe for a catastrophe.  Because a failure of a line of code is equally devastating to the enterprise as the failure of a strategy alternative.  So, if you set up a situation that's divisive and people don't understand their relationships it will have a detrimental effect.

The next thing is, in terms of centralizing and decentralizing, that's always going to be happening.  The fundamental question is if you change it what's going to be impacted?  … what inventories are impacted?  … what processes are impacted?  … what locations are impacted?  … what people are impacted?  You have no way to assess the impact of the change.

Some of you have heard me argue this:  managing change is dependent on architecture.  If they want to change this building but they don't have architecture for the building, they can't change it.  Whoever's going to want to change it has to recreate the architecture.  If you want to change anything somebody's going to have to create the architecture. 

Probably the role responsibility for change ought to be in the general management domain — it ought to be the Executive VP who's in charge of change management.  That's who ought to own architecture. 

If you have that kind of facility, and you have an understanding of the levels specialization we need, and you know where the dependencies are, then you can choose to centralize or decentralize.  You just have to know what the impacts are.  Right now we don't have any way to diagnose the problem, to do impact analysis of the enterprise. 

Centralize, decentralize — there's no one way to do it.  But if you're going to change those alternatives then you'd better know what's impacted.  Otherwise you can't change things … it would be like trying to change this building by knocking out those two posts there in the back of the room.  You'd better be careful about what you going to change.

  We, the enterprise.  I like that.

We've got time for one more question. 

Audience:  Here's my statement. 

In the future the users will be the developers.

Okay, we've gotten rid of everyone now.  It's just users.  <laughter>  Those of you who thought you had a job?  Nope, that's gone too. You were agreeing, Steve?  Okay, explain yourself.

  This touches a little on the previous question:  the oscillation that you see in organization structures about centralization/decentralization is really because those conversations are about power; they're about control, and they're about the management of work. 

The concept of a hierarchical organization is about control and management of people.  I think if you hear the messages coming out of some of the speakers, especially the keynote, we're moving into a world of collaboration; we're moving into a world of integration; we're moving into a world where we're putting capability into the hands of people. 

So, I like that statement — it's a bit radical.

Then again, if you look it's already happened.  There was a time, back in the 80s and the 70s (which I don't remember because I wasn't born then), we've already put power for development into the hands of the users.  We gave them Excel, and they could run their own reports.  We centralized data and we bought APIs so they could derive that data.  We're putting more intellectual power and more cognition into cell phone applications so that they can do their own processes. 

Technology and capability have a way of doing that.  And when you put the power into the hands of the people who are using it, you get very efficient use of programming.  A lot of users out there can't do macros in Excel — they can't develop websites.  But a lot can.

I think this is a natural progression for people.  Technology gives us the capability to do things that previously were the domain of IT.  And I think these questions about "Does it live in IT?" or "Does it live somewhere else?" are primarily questions about power and the control of people.

So, looking forward fifteen years, I see that as a major trend.

  I would disagree with Steve because what the enterprise needs are engineers — and engineers of a type that are able to construct complex organizations that are based around intellectual capital and business capability. 

Users have real daytime jobs to do, and they're going to optimize locally.  That's not going to solve the enterprise problems or problems of integration or of engineering future configurations of businesses.

So, I'm going to have to disagree … depending on what the meaning of 'user' is.  That may be where the disagreement is. 

  My view on this is that I think Steve is right, except someone's got to develop the capability for them to do all that you've described.  All the things Steve talked about?  Someone developed that so that people could then do things for themselves. 

So, maybe our IT departments become more about making sure that users have capability to do more things on their own.

  I would suggest that all this is going to be dependent upon the governance system.  You can allow the users to do many things, but you don't want them to change structural things within the enterprise. 

It's like the building codes for your house.  If you go down to the city you'll find out that they will allow you to change some things in your house but not everything.  You'll have to comply with the building code because if you change the wrong thing the house is going to come down.  So you don't want structural changes to be made indiscriminately.

On the other hand, if you want to move a picture around you can do that.  You can do a lot of things within your house.  But if you begin to do things that will damage the integrity of the house then you have a problem.

So, I think the question comes down to the governance system.

  We've had the unfortunate consequence, John, of putting power into Ron's hands because if you can put those business rules into the hands of the individual in the house then they can do that stuff on their own.

  Sorta called 'anarchy'.  <laughter>

Wrap-up

On that point, let's wind it up quickly (before they think of something more to say).

I'd like you to join me in thanking our gurus for this session.  <applause>

And, gurus, I want you to thank these folks for turning up.  <applause> 

Before we move on, Gladys wants to say a word.

Gladys Lam:  I think we all have to thank Roger for all the effort he put into this panel.  I can tell you, organizing four gurus is not an easy task!  <applause>

# # #