Panelists

	Roger Burlton	President & Managing Partner, Process Renewal Group Founder, BPTrends Associates
	Ellen Gottesdiener	CEO / Agile Product Coach, EBG Consulting, Inc.
	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. In the digital enterprise, time-to-market is critical and 'good enough' quality will do.


2. The most critical asset of a business analyst is a digital mind.


3. Deep subject-matter expertise is irrelevant for a business analyst, especially in agile business analysis.


4. Do you think that 'business analyst' as a profession will stay in the market for long as a generalist, or will it be split into a set of specific, more narrow professions?  For example, business architect, business process analyst, and so on…


5. Corporate America today is acknowledging the value of business analysis more and are now committed to investing in business analysis within their organizations.


6. Empowerment, more than rules, processes, or architecture, is key to business agility.


7. Evacuating the IT department to weave IT into the business optimizes business capabilities.


8. What work are you personally, or your organization, doing with universities (or other schools) to make sure we start educating at that level the profession of the 'business analyst'?

Welcome & Introductions

Good afternoon.  My name is Roger Tregear.  Thank you for joining us for this last session of what's been a fantastic conference, Leading Business Excellence.  As you know, the guru count here at BBC is just off the charts, so we have this session at the end to capture some of these gurus in one place and challenge them, and ourselves, with some ideas leading to business excellence.

I'm often asked how we define 'guru' for this session.  It's a complex thing to do.  I can tell you that G–U–R–U is not the acronym for "general understanding, relatively useless." <laughter>  That's not the way we use it … although you can be your own judge of that.

My first task here is to introduce the panel.  Of course, it's a panel that doesn't need any introduction.  I'm going to do it in reverse-alphabetic order so that at least for once in his life, John Zachman's not at the end of someone's list. <laughter>

You probably think that these people are here because of their skills in architecture, rules, analysis, and process, but that's just a small part of their superpowers.  For example, John's parents had the amazing forethought to name him after a framework.  And that's just as well because otherwise he'd still be a baggage handler at O'Hare Airport.

Ron Ross — you may not know this, but Ron Ross is a juggler.  A literal juggler.  He's going to do a demonstration later, and he is available for parties if you need some entertainment.  So, gurus, if you find yourself under attack today, go for the juggler. <laughter> <applause>  My work is done; I'll go now.

Ellen Gottesdiener started much of her working life on the working side of a hotel bar.  And, like most analysts, she quickly graduated to the other side and has put in the necessary ten-thousand hours to become the expert.

Roger Burlton, you may know, runs marathons.  So far, he's done the London Marathon, the Boston Marathon, the Vancouver Marathon, the BBC Marathon. <laughter>  And at each event he's had a personal best.  So, this is, of course, continuous marathon capability improvement.

So, you thought these people were about:  architecture, rules, analysis, and process.  But it's actually about:  baggage, juggling, alcohol, and running.  <laughter>  Oh, hang on — that's the same thing, isn't it?

They're obviously well trained, which gives you some idea how you get to be on the guru panel.

Now, I need to explain to you how this works.  You've got it already, haven't you?  Red, Green:

    

Okay.  I'll explain it to these gurus because it often takes a bit of work.  Many of you have seen the statements that we're going to test here today.

We'll put those up on the screens and our gurus are going to be asked to say, "I agree" (green / thumb up) — on the back, we've got it written, for these guys.                 Or, if you don't agree, it's a red thumb down.  And, again, we've given them a cheat-sheet on the back.

So, we'll put the statement up; they'll respond; then we'll have some discussion, in a very polite and orderly way — just short comments from some of them.  They're all good at short comments, with the possible exception of one of them.  We're all looking at John <laughter> — I don't know why. 

And then, a couple of times through the session, we'll have an opportunity for you to pose a statement to the gurus.  So, be thinking, as we go, of the sorts of things you'd like them to talk about.

Okay.  Are we good to go? 

Here's the first statement.  Gurus, do you or disagree with this:

In the digital enterprise, time-to-market is critical and 'good enough' quality will do.

Agree?   Disagree? You all disagree!  Okay.  Roger, you've got the mic.

  I thought this was going to be fun.

What I would say is that, of course, we can all sit here and say, "It depends."  For the business we're in, it depends and it's going to cost you a lot of money to find the right answer.  Let me point to two examples, both in the telecommunications business. 

If you're slow to market you're just not going to be successful.  A great example of that is Blackberry / RIM.  Their big issue was that they were just late, with everything.  There's nothing wrong with the stuff they did; they just got it there two years late. 

But then you can look at another example (and this is personal for me):  I finally got off my Blackberry and I bought a Samsung Galaxy Note 7. <laughter>  You're laughing, but it wasn't very funny when I was told I couldn't take it on the airplane.  I'd finally gotten it all set up — learned a new operating system, got all the icons in the right places, got it figured out — and then they said, "You gotta bring it back."  So, I had to go back to my Blackberry for a while.  That's a great example of rushing to market with something that is not quality.  What did this cost Samsung to not be there?  But also, what did it cost Blackberry to not be there?

I think there's something in the middle.  Whatever we bring to market these days, if it sucks, everyone's going to know and they will tell everybody else.  So, maybe we get there fast with the core base product and then just iterate and learn and evolve from there.

  So, I put my card sort of sideways because sometimes time-to-market does matter.

The focus for me is on what is the definition of quality?  Because 'quality' is value to somebody.  What might be quality to one person is not to another. 

Talking of examples, are you familiar with a company named Theranos?  They came out with a digital blood analyzer.  They were the darling of Wall Street; the CEO was lauded — and it turns out the product is not right; it's not validated.

The quality of the product does matter in a regulated environment — when we're talking about healthcare.  But if we're talking about adding capability, for example, to be able to unlock a car in a car-sharing business with your phone, what is the degree to which you can fail (have defects) in that? 

So, yes, the focus needs to be on quality.  If I'm in a parity situation, time-to-market may be more important, where I have to build something quickly.  It's really a balancing act and depends on what is quality?  It really is in the eyes of the beholder.

  When it comes to quality, the idea that one size fits all is just incorrect.  It depends entirely on the problem space.

Let me give you some examples.  A lot of the time in marketing, if you hit 80% of the target customers you're considered to be doing really, really well.  (Actually, for direct mail it's more like 5%.)  So, the criteria for quality there is relatively low.  On the other hand, one of our clients is in immunology and, there, 80% quality is just not going to do because that means 20 out of 100 children that are vaccinated have problems.  So, here quality is 99.99% or you just don't release it. 

We really have to get away from the idea that there is one sense or threshold of quality that's going to be suitable for everybody.  And that is completely separate from how long does it take you to get something to the market.  If the Zika Virus had taken hold you'd want the CDC to come out with an effective vaccine quickly, very quickly.

  So, it probably only ever needs to be 'good enough'?  Because 'good enough' is a sliding scale, and 'good enough' is the target, isn't it?  I mean, do we ever need it to be better than good enough?

  It doesn't hurt to be better.

  Oh, it costs a lot.

  Gee.  That's a hard question, Roger.

  Yes.  That's why you're here. <laughter>

  You've confused the question, just as I hand the microphone over to John.

  He'll just have a quick comment now.  That'll be good.

  Well, I can answer that question in an hour and a half or so.

  That's what we're worried about.

  Okay.  I disagree about the quality issue because the definition of quality, coming out of the Quality Institute, is:  producing end products that meet the requirements as defined by the customer.  So, the definition of quality is whatever the customer is looking for.

I agree, however, that the time-to-market is approximating zero.  In fact, a lot of study has gone on about that.  I quote Alvin Toffler's material, where the rate of change is increasing as the body of knowledge is changed.  The ever-increasing body of knowledge, feeding the great engine of technology, creates ever-increasing change.  That's why you see greater change increasing dramatically.  That will drive the time-to-market down to approximately zero at some point in time.

If your customer clicks on your icon on his screen and whatever you produce is not meeting his requirements, it is very easy to click the adjoining icon, from somebody else, to produce whatever it is that's wanted.  So, good enough quality is not adequate, I believe.

That raises another interesting issue:  In the context of the information technology community, the customer typically is general management of the enterprise.  And when general management starts to want something — whatever it happens to be — and they click the mouse to demand something from IT, and IT doesn't produce whatever it is that they have in mind, there's a problem.  As a matter of fact, most of the CEO surveys for the last twenty-five or thirty years would suggest that alignment is in the top-ten issues that the general management people expect IT to fix:  Are you producing implementations that are aligned with the perceptions or the requirements as defined by general management?  That means that, if the time-to-markets are to decrease and general management is demanding a different enterprise, now you've got a real challenge.  Something has to be done before you get the order.

The Japanese taught us a lot of hard lessons over the past thirty-five to forty years, changing the name of the game of manufacturing from a make-to-order to a provide-from-stock to an assemble-to-order strategy, which basically says you want to assemble custom products, mass-produced in quantities of one, for immediate delivery — mass customization.  It's my argument that we're going to have to do this also for the enterprise:  be able to mass-produce the enterprise on demand. 

Of course, many of you've heard me argue this case before:  if you don't have any architecture, if you don't have anything in inventory before you get the order, then you'll never make it.  So, reducing time-to-market is really a critical issue, and quality is also a critical issue.

  Okay, so we need both.  That's good.

We also polled delegates, and many of you have responded, so this is what you thought:

AGREE:   43%     DISAGREE:   57%

You were 40/60 split:  43% agree; 57% disagree.

Next statement:

The most critical asset of a business analyst is a digital mind.

Agree?  Disagree? Ron, you agreed.  What is a 'digital mind'?

  John handed me the microphone as if he knew I was going to be the one.

Well, I agree with the statement, but not in the way that it was probably intended.  Because in the future we're going to have machines that are capable of deep learning.  It's already happening:  There was a session just now by Sridhar Iyengar (IBM Distinguished Engineering) on IBM Watson and the application of Watson to regulatory documents and, in the near future, requirements documents.  There are going to be tremendous analyst companions to help us sort through large volumes of boring text and requirements (not to say that requirements aren't boring, but that's a different issue). 

The digital mind that I'm talking about is going to be a machine companion, and it's going to dramatically reshape the way that many professions operate.  It's already happening in medicine and will continue to happen. 

And it will get here.  It will affect your business analysis activities.  Because, for example, wouldn't it be nice to have an automated assistant that could help you, after a day's session, to give you insights that you may have missed if you're the facilitator?  Or be able to read thick requirement documents and find similarities and overlaps and even conflicts. 

That's right around the corner — it's going to happen.  Next year at this conference we're going to be talking more and more about digital minds, in the sense of machine minds.

  There's an interesting take on 'digital mind' — something that you carry along with you.  I discussed this with Michael Rosemann, who some of you know and all of you will come to know.

Professor Michael Rosemann, QUT, is doing a lot of work on the digital mind.  He thinks of it as:  People who can recognize the different business model — one that's enabled by digital technology.  You can look at spare assets, those not being used, and create a platform in which they can be used. 

That's Uber, and lots of other things.  Or Google wants a driverless car because we're all wasting too much time driving — billions of hours — and not enough time searching and using their platform.  It's about 'digital attention'. 

  As Sridhar said, machines don't get tired; they don't get bored; they don't have emotions.

  I've worked for some of those people.

  Roger, we're not here to talk about your personal life.

  With all due respect to Michael Rosemann and Sridhar — both of whom I appreciate — however, to my knowledge the brain researchers have not yet discovered that the brain, the human brain, is made up of 1s and 0s.  Therefore, I question the fact of the reality of a digital mind.

However, if the question read, "The most critical asset of a Business Analyst is a mind," now that would really make a lot of sense. <laughter>  Because I've got to admit, when you look around the universe these days, you wonder if there's a deterioration to mindlessness around in the general population.  But, hopefully, not in the Business Analyst population.

  Ellen, we'd better give you a chance to stand up for your community there.  Don't you just hate it when John Zachman starts out "With all due respect…"?  <laughter>  You just know you're going to get torn apart.

  Well, one of my beefs with the question is "business analyst" because it's not about the role, it's about the goal / the work.  So, that's one thing.

The 'digital mind' aspect — in terms of the cloud and cloud computing and social media and the Internet of Things — of course, we need to be able to understand these possibilities.  Which leads to, well, how do you find possibilities?  How do you evoke possibilities? 

What is important for this work is empathy for the customer, compassion, the ability to elicit, to facilitate, to collaborate.  Yes, sure, we want to be able to look at business models, but there are also techniques and tools and design thinking and understanding customer journey.  When we take a product perspective and understand the customer of the product, as well as the business and the technology possibilities, now we're opening up possibilities — we can look for those business models that you were talking about that Professor Rosemann focuses on.

So, the ability to do that kind of work is not just about the digital 1s and 0s, which I really appreciate.  We need to exercise our wetware just as much.  It's just as much about heart as it is about head.

  Okay.  Let's check what the delegates said.

AGREE:   11%     DISAGREE:   89%

Oh, 90% disagree.  I shared that statistic with Michael Rosemann and he said, "I've still got a lot of work to do, I can see." <laughter>  Roger, did you have something you really needed to say?

  I just wanted to quickly add that I agree very much with what Ellen said.

You can take the word 'digital' and plug in 'this-year's-word' — and we've heard this for a long, long, long time — every single time, we thought, "This is it!"  "This is the last one."  "There won't be anything beyond all this."  But there always is.

  I guess that's good to know.  There's something more to come.

Okay.  Let's have one more and then after we've done this statement we'll get a question or two — not many; we don't have much time — from you.  So, if you want to start thinking about it, and you might even race over to a microphone if you want to.

So, here's the next one:

Deep subject-matter expertise is irrelevant for a business analyst, especially in agile business analysis.

Agree?  Disagree? All disagree.  This is your world, Ellen, so kick us off.

  Well, how can you not understand the product domain?  And what is this picking on agile business analysis — this applies whether we're working in an agile context or not.

In some ways, it's more important, yes indeed, when we're working in an agile context because we are really needing to be focused on the value of the product — that's often the big mantra of agile.  But can a person doing business analysis work in a discipline not have domain expertise and help the team survive and thrive?  I think that's possible, but having domain/subject matter expertise really is critical. 

I've worked with teams where people from the business side move into analysis, or even product ownership.  (There is a difference, by the way — it comes down to decision making and the authority to make decisions.)  Understanding the domain and having understanding of the customer, the users, is really, really crucial.  You have to go out and learn, in some cases.  Marty Cagan, for example — you might want to look up his work in the product management arena — talks about going out and understanding the customer.  And that requires domain expertise.

  I would actually like to nominate 'agile' for the adjective-of-the-year award. <laughter>  Because everything now has added this as a qualifier.  We get caught up in these fads of things like that.

I really believe, based on all the experience we've had, that if you have some reasonable knowledge — even if you're just a business analyst who's facilitating — that is really quite helpful.  Having some subject matter knowledge helps you know when what's coming across is complete BS and when what's coming across is intelligent.  If you can't make that kind of assessment it's going to be very difficult. 

But I also don't believe that you can get away with just being a subject matter expert and not have good analytical techniques and methodologies.

  That's very agile of you, Roger.  Thank you.  Ron?

  I disagree, but not for the reason you probably think.  The part that I disagree with is "especially in agile business analysis."

Generally speaking, I think it's impossible to have deep expertise and be a good business analyst.  So, what you need is the right learning tools — the right structural tools — in order to become very familiar, very quickly, with the deep knowledge of the subject matter. 

There is such a technique — we've talked about it many times.  It's concept modeling.  If you come to grips with the vocabulary of a space and you define the concepts and you structure those concepts so that you know the relationships between the concepts, you will sound far more intelligent than you really are.  

Now, I'm not saying I've made my career doing that <laughter> but I'm just sharing with you some secrets of success.  A tool like concept modeling is relevant for any business analyst, and you should use it any time you really dig into a subject field that you're not familiar with.

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

  John's tapping me on the arm … and it's not a love tap.

  30 seconds, John.

  Mention of the word 'agile' reminds me of an old friend, Alice Rigby, who retired years and years ago.  She said, "Every time I hear somebody say, 'All you gotta do is …' I put my hand on my wallet."  So, when I hear the word 'agile — "All you gotta do is agile" — I put my hand on my wallet because I know it's going to cost me money some place or other before we get done.

In any case, on the issue of deep subject matter knowledge (I'm going to say 'knowledge', not expertise) if you don't understand the enterprise, or have availability of a knowledgebase that describes the complexity of the enterprise, at the point in time when you have to solve problems it's going to be too late.  Because it's too complex — the complexity will be too great.  So therefore, no amount of deep knowledge is going to help you.  You're going to have to have a knowledgebase, which I would observe is a set of descriptive representations that constitutes enterprise architecture.  If you don't have that, there's no way you're going to be able to diagnose the issues and pose various solutions to solve whatever the problems are.

  Okay.  Let's see what the survey said.

AGREE:   43%     DISAGREE:   57%

Again, a 40/60 split.  40% agree.  It's kind of interesting.

Now, it's time for a statement from any of you.  Would you move to the microphone so that we all can hear you please.

Audience: 

Do you think that 'business analyst' as a profession will stay in the market for long as a generalist, or will it be split into a set of specific, more narrow professions?  For example, business architect, business process analyst, and so on…

Ron, you've got the microphone; do you want to handle that one?

  I think that there's a place for deep subject matter expertise in certain fields.  There are some areas where there are specialized skills.  So, some will turn into more specialized kinds of analysts.  But some won't.

There are areas where deep understanding and skill is necessary.  For example, business rules is one of those because you don't take that subject lightly.  Business process, frankly, is another one — in order to truly innovate from a process point of view.  Enterprise architecture is another.  That's why we have these trails at the conference.

On the other hand, the skills that just about every business analyst has — gaining consensus, knowing how to dialog effectively, knowing how to handle the human dimension, being a change agent — every business analyst needs these.  So, the answer (for me) is yes and no.

  I really think the true value of a business analyst is to bring connections among things.   You may have some specialization, but I don't think the integration aspect is going to go away.

If you look at John's Framework, all those columns are unique domains.  If you want to build anything out — specify how it's going to work — you have to start connecting the dots.  I think that's one of the key values of a business analyst.

  I would harp back on the point earlier that it's not business analyst but it's business analysis.  And, depending on the size of the organization and the complexity of the product domain, one person might embody more than one of those disciplines, like business architecture and analysis.

So, that is what I think we want to focus on.  The skills, as Ron said, are essential to have — leaders need to be able to shift often to collaboration, to facilitation skills, more than perhaps they do (or we wish they would).

  Okay.  Does John have something to say?

  I don't know that I can add much more.

  Thank you.

  Except I did … <laughter>

  How long does it take you to say nothing?

  I did hear a differentiation between an architect and an engineer not too long ago, which I thought was interesting and significant.

The architect is more of a generalist who can understand and transcribe what the characteristics of the end object that the owner of the end object has in mind and can envision the end result.  The engineer is trained specifically in some domain for doing some actual design work around some specific academic discipline.  I thought that was a pretty good differentiation.

No one person knows everything; I'll guarantee you that.  The older I get, the more I realize how little I know about so many things.  Nobody is ever going to know everything — particularly in the complexity of the environment that we're beginning to have to live in.

If you look at the characteristics of the information age, it boils down to extreme complexity and extreme rates of change.  Those are the two essential things you have to deal with.  And no one person will be able to deal with it.  So, there's a lot of room for creativity, a lot of room for specialization.  But I also think there's a need for somebody to orchestrate the whole thing with more general understanding and vision.  That may be the role of the architect.

  Thanks, John.

Gladys Lam:  Roger, we have a question here.

Audience:  First, thank you for a great conference.  I'll state this as an agree/disagree statement.

Corporate America today is acknowledging the value of business analysis more and are now committed to investing in business analysis within their organizations.

They see the value but won't commit to the funding?  Is that what we're saying?  Is that changing — are we getting more commitment?  Surely, we are.  No?  More funding?  More focus?

  You know, you can do a simple calculation on the number of man-hours involved in companies sending you guys here.

Say, a thousand people (I think there are more like fourteen-hundred, but to keep it simple say a thousand) and twenty hours of conference time, that's twenty-thousand hours of investment time in our learning together and pushing this discipline forward — I don't think that's insignificant.  I think it's great. 

I'd like to see more.  I'd like to see more people here next year.  But it is happening.

  The only thing I would challenge on that is, "Who is making the commitment?"

I don't necessarily see as strong a commitment coming from the C-level — especially the operational C-level of the organization.  I assume we see it from the people running BA groups, which is a step in the right direction.  But we still have a long way to go.

  Okay.  Thanks for that.  We'll have another break for a statement before we finish.

Back to here — are we ready gurus?  Here's the next statement:

Empowerment, more than rules, processes, or architecture, is key to business agility.

Agree?  Disagree? All disagree.  Ellen, would you like to explain yourself?

  So, I looked up 'empowerment' in the visual thesaurus (my favorite place to go for term definitions) and it says:  "conferring legality or sanction or warrant."

First of all, empowerment alone isn't going to get us toward business agility.  There are a couple of problems with that statement, but let's just talk about the empowerment first.

You can have empowerment, but if you don't have trust nothing's going to happen.  Nobody's going to move quickly.  You can have empowerment, and if you don't have collaboration nothing is going to happen. 

So, it's a little bit myopic to say merely "empowerment."  It's good; it's all good stuff to say that a team is empowered to do work, and so forth. 

The other problem with the statement is when you say "rules, processes, architecture" that's some of the story.  But if we look at John's Framework, we know to ask, Where's the data?  Where are the quality attributes?  Where's the environment of use?  We need to look holistically at what it is we're trying to be agile about.

  Oh, boy.  [hands the mic on to John]

  When I first saw the question I thought, "Now, this is ridiculous."  If you don't understand — have deep knowledge, have a knowledgebase, know how the enterprise works — and you expect to empower somebody to write a few more lines of code (or do anything), they're going to be doing it out of context.  It will be a solution in search of a problem.

So, somehow or other we've got to start with a better understanding (a knowledgebase) of how the enterprise works.  And it's complex, with relationships between all the components.  When you start looking at these kinds of relationships, if you want to diagnose problems, and you touch any one thing in the enterprise, you have to know all the other things it's dependent upon or it touches.  Otherwise, you create unintended consequences in whatever you do.  You have to be careful about this.

I'm not necessarily negative on empowerment, but empowerment in and of itself is not going to fix the problem.  You've got to have some kind of knowledgebase to work with.  If I was a business analyst I would be arguing vehemently for this. 

I don't believe we do diagnosis very well in the enterprise.  We understand where the pain is — we want to build an implementation or to address a solution to a problem — but first we need understand what all the elements of the situation are in order to be able to diagnose it.  A multiplicity of potential solutions can be posed.

I argued the case on Monday in my tutorial that I don't think many people know the profound significance of this.  People argue that enterprise architecture takes too long and costs too much.  I'll tell you it is quicker to create enterprise architecture than it is to build implementations.  And if you're not doing architecture in the context of some industry agreed-upon set of descriptive representations, we're not going too far.  You'll have nothing repeatable, nothing predictable.

I like to use metaphors:  Before Mendeleev published the Periodic Table, there were a lot of chemists — they were alchemists, actually.  But there was no coordination, no collaboration — everything was by trial and error, best practice.  Until you have some kind of order, some kind of ontological structure, there's no way to deal with the complexity and the extreme rates of change that we have to deal with these days.

I have another hour and a half on this one. <laughter>

  That's good — that's scheduled for the next hour.  Roger has something to say.  Ron, you too?

  "Rules, processes, and architecture" — these don't lessen business agility.  They lessen anarchy.

The basic problem is lack of structure, lack of deep knowledge reservoirs (including architecture and business rules).  They don't lessen empowerment — they increase empowerment.  I'll just leave it at that.

  We've worked with organizations that are 100% flat — no management hierarchy whatsoever.  Everybody is "empowered" to do what they have to do.

But in that organization, they deal with a philosophy called "freedom within a framework."  And so, the empowerment is within a set of guidelines — a set of rules, a set of reusables.  And those organizations are out-performing everybody.  But it's not because everyone has a free-for-all.  It's because they know their bounds; they know how they connect; they know what they're responsible for; they know what the measurements are for what they're doing.  There's a strong structure.  Then the culture can work, as long as you have a reasonably strong structure against which you can work.

  Okay.  Let's see what the survey said:

AGREE:   70%     DISAGREE:   30%

You, the delegates, agreed 70%.  That's interesting — 70% agreed.  This might be a reflection of how dis-empowered you all feel.  But I guess we would all agree that empowerment is necessary but not sufficient.  We've all been on the end of those emails that go out that tell us that we're all now empowered to be agile, or whatever.  And good luck with that.

Okay.  Next statement coming:

Evacuating the IT department to weave IT into the business optimizes business capabilities.

Agree?  Disagree? Oh, here we have a split!  All right, Roger, you've got the microphone.  Why do you think that's not true?

  What I think is true is that the nature of the IT department is going to change.  I really do think it's the IT department's responsibility to establish the infrastructure and the enabling core capabilities that are required.

We're working with an organization right now that we're helping to deal with the issue of crisis management.  This is a large financial institution; regulation is an issue.  Part of the crisis management is cyber attacks.  Try to deal with a cyber attack without an IT department!  Try to deal with connecting the dots of being end-to-end with a customer without an IT department.

But I do think that a large part of the traditional stuff in IT departments will move.

  Yup.  Okay.  Ellen, do you agree or disagree?  (I forget.)

  I agreed.  I'm not thrilled with the verb "evacuating" ….

  These statements are made to be deliberately provocative.

  Provocative — definitely.

  And these are not statements to which I'm saying I agree.

  So, the best work that I've seen in organizations is where there are fewer silos and we have all the disciplines necessary to get to the outcome we want.

Years and years ago there was something that predated the sexy term 'agile' (and cross-functional teams); there was an approach that was discussed in Harvard Business Review, that a lot of teams (especially pharmaceutical teams) did work with.  It was used before SCRUM became popular, with cross-functional teams.  They were delivering to market (and I'm talking about a pharmaceutical product, which you know is a multi-billion dollar/multi-year product) and integrating all of the skills together.  There was a nice model for agile fluency — it's more of a team-based model.  And in that model, you start with a focus on value.  And then you go to deliver value.  Then you optimize value.  And then you optimize the system. 

There are very few organizations that really operate in that way.  But in that sense the technology skills are embedded within the team, and they are product and value focused.  That would be the panacea, actually.

  It always seems like getting better at cross-functional collaboration is the answer to so many questions, isn't it?  Or getting back to being good at it.  Maybe we used to be better at it.

  Almost twenty years ago, John Zachman sent me an article in the mail to read.  (He still does that, by the way, and they're stacked neatly right on my desk.)

This one made such an impression on me that I have an old, yellowing copy posted to my cabinet.  It was called "The Next Information Revolution," by Peter Drucker in Forbes.  It was really a fascinating article, pointing out that in the 1400s and 1500s, printers were a brand new phenomenon.  It was a very scarce commodity; it was exciting.  It was revolutionizing the information exchange.  And in those days, printers were dining with kings and queens because of their clout, because of their importance in this new discipline.  But by the late 1500s the printers (printing) had become more or less a commodity, and they were no longer dining with kings and queens. 

Now, I think we're going through a similar phenomenon — long-term, multi-decade — with IT.  The day is coming when they will no longer dine at the troughs of the financial resources of the company, as we learn how to disseminate brainpower (computing power, machine power).  And, yes, IT will always be around, but it's going to change dramatically — how we build systems — in the next ten years.

I just want to say, I know what a struggle it is for many of you, trying to reach consensus with IT and playing equal partner.  Certainly, I appreciate that.  That's why, partly, we're all here.  I want to congratulate you for being sort of the founders of that change in attitude in the movement.  It's going to be a long road, but you guys are on the right side of history and in the right place, at the right time, to make that happen.

  Well, I still read paper, actually.  And I sent Ron the article in the mail.  I don't read green-screens.  (A lot of people don't know what 'green-screen' means any more — is that a sign of my old age and 'non-digital mind'?)

I disagreed with this statement, although the article that Ron referred to is profoundly significant.  Drucker basically said that this is the 4th Information Revolution, not the first one.  The first one was the discovery of papyrus, where you could record things — record some kind of data.  The Second Revolution was the accumulation of large bodies of knowledge, like in scrolls (attributable to the Chinese).  The Third Revolution was the printing press, Guttenberg.  This is the 4th Revolution. 

The price-performance improvement from the information profession in Europe, which was monks copying scripture, to the printing press, is about the same price-performance improvement from the ENIAC or ILLIAC to the modern PC.  So, we've done this all before, it turns out.  As Ron referred to, initially the technologists are hailed by kings and princes.  But within a short period of time they become common laborers — the technology becomes labor. 

I really think there's something good here.  But I disagreed with the statement for this reason.  There's something good about everything, but no one thing is good for everything.  We went through one of these before.  This argument about "evacuating the IT department" — we did this once before, not that long ago.  The real problem in IT (it was DP in those days) was the mainframe:  You've got to get rid of the mainframes, and all your problems will be solved.  We de-centralized everything into servers (or whatever). 

Now, did that solve the problem?  A lot of good things happened, but a lot of bad things happened, too, you know.  It complicated things; we lost control; we decentralized some things where we really didn't understand the unintended consequences. 

So, it's not either/or — centralization or decentralization.  You need to compensate for the implications.  If you're going to decentralize you are going to lose consistency, integrity.  You need to compensate for that somehow through the governance system.  If you're going to centralize you're going to lose something:  creativity, innovation.  So, you need to compensate for that.

It's not a matter of just walking away from the IT department.  We start thinking that the next technological innovation is going to solve all the problems — evacuating IT will solve all the problems.  You'd better be careful about that and think it through. 

I do agree that the technology is not the issue.  The way it manifests itself, in my perception, is that the end object is not to get the code to run.  A lot of us in the information community think that the end object is to engineer the enterprise so it does what you want it to do.  And you design it so that you can change it fairly easily, with minimum time, disruption, and cost.

In that sense, I agree with the statement.

  I'll say one more thing.  The sustainability of the way we build systems today is horrendous.  And so, the level of interfaces is going to have to rise — and it will rise — to a more human level.  That's going to take a lot of IT out of the loop.  Just watch it happen, over the next ten years.

  Before we go to the audience for a final question, let's look at the survey results.

AGREE:   46%     DISAGREE:   54%

Here's the result — a 50/50 split.  So, I imagine 50% of you work in the IT department. <laughter>

We have time one more question from the floor.

Audience:  Thanks for such a great conference.  My question is about sustainability of the BA as a profession:

What work are you personally, or your organization, doing with universities (or other schools) to make sure we start educating at that level the profession of the 'business analyst'?

My background is industrial engineering.  In schools we see a lot of emphasis on artificial intelligence, but what are you working on to see that the broader skills for business analysis are being taught?

Who's going to answer this?  Ron?  Roger?

  As an industrial engineer myself I understand what you're asking.  I go back to my university and help teach one of the classes.  What we notice is that so many of those people coming out of industrial engineering do end up as business analysts in non-industrial environments.  So, they're getting a lot of the education that they need there.

But in my own experience, there are relatively few places that are actually teaching this wider view of the world.  I think this is true not just in business analysis.  It's certainly true in architecture.  And it's certainly true in general management. 

We're trying to get people to manage cross-functionally but name more than four or five universities in the world who are doing MBA programs, other than teaching finance, HR — all these functional disciplines.  No one is teaching how to be a cross-functional manager, how to do cross-functional integration, with perhaps the exception of Queensland University of Technology, Vlerick School in Belgium, and a few other places like that around the world.

We've got to change the educational side.  But that has to start with the vision of the educators to see that it's not just about teaching these various functional areas that are going to keep everyone stuck in their silos.

  Even in those places, Roger, like QUT where there's a huge information systems school, I don't know how much is happening in the business school.

  No, it doesn't.

  We preach getting rid of silos and we teach that within silos.  I wonder why that is.

  There's a quote by Jay Forrester, who was the author of Industrial Dynamics.  It was from a speech he made at Seville University in 1998.

I won't have the quote exactly correct, but I hope I'll be able to convey the idea.  He said, 'Airplanes designed by committee and intuition would perform no better than an enterprise designed by the same methods — it would create an airplane that no pilot could fly successfully, just like an enterprise would be created that no manager could manage successfully.'  He went on to say that we train pilots in trade school but we train airplane designers in universities.  He foresaw the future universities teaching people on enterprise design, in effect. 

Of course, I've argued this case for a long time myself because I think that the design artifacts for creating a complex object like an enterprise are exactly identical to the design artifacts for creating airplanes and buildings and locomotives and battleships and so on. 

So, I think this is a really significant issue, and I don't see a lot of support in the university environment because they tend to be very market sensitive.  If the local enterprises are hiring Java 2 programmers then the schools will have a Master's Degree in Java 2 programming.  Are they making the investment in teaching these other topics like enterprise design?

In any case, every time I have the opportunity to be in a university environment, I really appreciate that because I think that to expose the universities to these kinds of concepts is really profoundly significant.

  A good university does some of the right stuff.  I guess I'm biased because I think the most fundamental, important skill of business analysis is communication — deep, clear, unambiguous, insightful, rich communication.  And that is something that is taught in liberal arts schools.  It can be encouraged and so on.

In terms of sustainability, if you want your career to be sustainable there will never be a time when there's not a need for great communicators.

  The one thing I would add in terms of universities is one of the flaws that I've seen (and as discussed here) is teaching a discipline in the absence of other disciplines.

Some of you have heard of this, from the world of design thinking:  T people, where you have deep expertise in one area (in the stem of the T), but you have appreciation and empathy for the other disciplines (the horizontal bar of the T).  That's a lack in many university programs.

Another thing that I've seen work really well is to have interns from the university on our teams.  In many ways, I think that's almost a requirement — in order to prepare for the real world.  So that people learn how to operate on a team, a cross-functional team, and experience what the real work world is like. 

If you have any influence over your university, or if your organization can bring in interns, that is really powerful.

  Okay.  This brings us to the end of our time.

Wrap-up

I always enjoy these sessions.  We have these deliberately-provocative statements that are designed to pull out of people some of the deep-learning that our gurus have had.  So, why don't you join me in thanking our gurus for the session. <applause> And, gurus, we can't do this without them, so a round of applause for the delegates. <applause>

Gladys Lam:  And I want to thank Roger Tregear who put in a lot of work.  You should have seen all the emails that went back and forth for a whole year to put this together.  So, thank you, Roger!  <applause>

# # #