So the first thing I want to say is that for the last 20 years, I've
made the same announcement at the beginning of all my talks.
No Microsoft products were used in the making of this presentation.
This is all HTML.
I've always made my slides on HTML.
And so they work forever, and you can access them forever.
In fact, all you need to know is this URL here, and you can get the
entire talk.
And throughout the talk, many of the slides have links to further
information on them.
So you can go through the slides and find your little Easter eggs and
check out more information.
You can go to this talk, in fact, which is a longer version of the
talk, more academic, and that talk has a link to the short and long
papers on this topic.
So there's as much information here as you would care to do.
Okay.
But I have to give the talk in English.
So let's go on.
I want to start off by talking about something that just happened to
Boeing.
They finally got their Dreamliner airplane in the air.
And the Dreamliner, the way they did the Dreamliner this time was
pursuing a very old dream.
In fact, it's so old, it's sometimes called the Northern California
dream or vision.
And that's a dream of outsourcing everything.
Very agile supply chains.
Everybody's connected.
Everything's just in time.
And we don't have to keep any inventory.
In fact, in the end result, and we've all written papers about this,
you could have very small companies.
In fact, one of the things I predicted is that in the next five years,
we'll all be working for ourselves.
We won't be working for companies.
You'll wake up in the morning and you'll go to your computer and
you'll see, what is my list of potential tasks I could work on today
with other people?
And you form these little flash companies.
And I'll talk more about that in a moment.
But the idea is everything is connected and you don't need to work for
a company.
And a company like Boeing won't need so many employees because they'll
outsource everything.
So they wanted to start trying this with the Dreamliner.
And it's necessary.
It's going to happen.
It has to happen for various reasons I'll go into in a moment.
And it's good, but it doesn't yet work.
And what happened to them
was the nightmare.
So what happened to them is they had delay after delay after delay.
It took them a year later than they thought to get this thing into the
air.
And there was a lot of, if you looked at the business papers, there
was a lot of coverage about this.
What was going wrong?
When was it going to fly?
Was it ever going to fly?
Companies that had bought these things were waiting.
They were spending money because of the delays.
It was extremely disastrous for everybody.
So the question is, what went wrong?
Well, this is essentially an IT problem.
Now, if you look at supply chains and what has to happen to supply
chains, you know that IT has certainly focused on messaging and
document standards.
So we can all share information.
You've got a supplier, you've got a manufacturer, you've got these
trading partners, these trading partners, you've got these supply
networks, or sometimes called web of work.
So everybody can freely exchange information.
Everybody understands everybody else today.
But while this is necessary, it's not sufficient.
So what's the next step?
Well, the next step is something you've heard about a lot.
Service-oriented architecture.
In fact, we teach this here.
I'm helping to teach this course, Service-Oriented Computing, where
you have an architecture that is built around services, and these
services are orchestrated, you have event monitoring, data extraction,
all the messaging, all the standardization.
And this is intended to solve all the problems of diverse supply
chains where everything is outsourced.
But it doesn't.
Now, again, I teach this, so what I'm about to say is a little tricky,
but it doesn't really happen.
Now, what really has happened is that the IT departments have made
their own life easier.
If you look at this service-oriented architecture and how it's done in
practice, the first thing you'll notice is that they've standardized
on a technology stack.
WSDL is the Web Service Description Language, SOAP is a messaging
technology protocol for sending around messages for these services
that are supposed to be described in WSDL.
MEPL is a technology for putting these services together.
Other languages support it.
You've got HTTP, TCP, IP, and a whole bunch of other technologies.
And the idea is that you know exactly what the technologies are to
send messages to each other about these services, and it all should
work flawlessly.
But what it really does is simply simplifies things for the IT
department.
Because when they want to hire a programmer, they say, do you know
XML, WSDL, SOAP, HTTP, do you know Access2, do you know Tomcat, do you
know Apache, do you know JavaScript, do you know... and there's a few
other ones, but basically they're all the same now in every company.
So this makes programmers interchangeable.
You know these, good, you're hired.
We don't like you, good, you're fired.
We can replace you easily.
We just need to find another guy who knows this.
And by the way, everybody knows this now.
So programmers are interchangeable.
So we've made things easy for the IT department.
Everything works perfectly for the IT department.
But this still leaves a huge problem for Boeing.
And I'm going to tell you what those problems are.
So here are some of the quotes from the articles about Boeing's
problems with their experiment and outsourcing everything.
One of the things they said was we made too many changes at the same
time.
Well, that indicates something's missing.
You know, they didn't have... they were missing something to manage
this change.
One of the things that I think was very interesting here is that this
guy said in order to order a single washer, he had to fill out
paperwork and wait a day to get it from an outside supplier.
And this one was very nice.
It talks about the elaborate supply chain.
It talks about the web of work.
That's a good way to describe what's going on if you want to build an
airplane and try to outsource everything.
You have a web of work.
It isn't a simple chain.
Everything is interconnected.
And so what they tried to do was take the current IT management of
supply chains, which is all built around interchangeable programmers,
and innovate the supply chain without innovating the IT that supported
the supply chain.
So the kind of problems that we saw here was there was a lack of
explicit knowledge.
So a solution to that is you need more knowledge management.
We teach that here at the university.
We had hardware processes, so we need more dynamic processes that suit
the immediate needs.
Well, we teach service-oriented computing.
We had insufficient process status change management.
We need better notification.
If you remember, though, that SOA stack, it had event monitoring on
there.
So why didn't SOA help with all of these things?
It should have.
Well, the reason it didn't, unfortunately, in practice, and I'll talk
about this in more detail, is that SOA doesn't work because right now
it's all marketing.
There's the IT guy.
There's the IT department, and they know what they need to do.
And then there's sort of the marketing department for these big IT
providers.
And they have a vision of SOA, and that's what they talk about.
But they talk about it, and it isn't done down in the trenches.
So there's, if you look at, I have a whole other talk which you can
click on here about this, but essentially there is a lack of
semantics.
There's a lack of these dynamic process and dynamic process
management, a lack of monitoring and responding to the change.
And you can, and I have, worked out how to define this sort of as one
set of things which I will call collective work, which I'm about to
define for you.
So the first thing I want to talk about very briefly is semantics.
And I don't want to talk about it too much because it's talked about
extensively everywhere.
The idea is very simple.
You write down how things are connected.
You write down what is a person?
What is an organization?
What is a document?
How do these things relate to each other?
These are common terms that we use.
You write down how they're related, both in terms of class hierarchies
and also maybe some axioms that constrain their use.
If you've got an end date and a start date, the end date should be
after the start date, for instance.
It's a very simple axiom.
So this has been done over and over and over by a lot of smart people.
It hasn't resulted in what everybody hoped would happen because
there's some hard issues, which I will mention briefly.
As I say, I won't go into this because you can go into some of these
other talks, but the fundamental problem is that semantics are hard
mainly because they're so soft.
We know a lot of things.
Formalizing them and making them explicit is really hard.
Formalizing all of human knowledge has been tried for the last, I'd
say, 30 years by some very smart people and millions of dollars and
euros have been thrown at it and the problems haven't been solved.
One of the problems is that doing what we do in academics is write
formulas like this, and that just doesn't go anywhere.
It takes years of study at the Ph.D.
level before you understand those equations.
What we need are to let business people say things like this, if you
want to rent a car from us, that's our service, but there's some
preconditions to the service.
You have to have a driver's license.
You have to be 18 years of age.
You have to be at our location on weekdays between certain hours.
Trying to figure out how to say those things in explicit formal
semantics in a way that business people can understand is very
difficult.
We know how to say this in academic languages, but not in business
language.
So that's one of the reasons that this hasn't taken off.
There are other things that are even harder, saying that this
particular part has to be manufactured so it can be inserted from this
end and not this end.
It's very difficult to say in formal semantics.
There's been a lot of proposals for fixing this.
One is that, we'll just go to Wikipedia, or semantic Wikipedia.
There's something else called SOA for All.
There's linked services, linked data services, which is also taught
here.
But there's no reason to think that any of these will solve these
problems.
And again, there's a link to another little paper on this.
Okay, and now I said a while ago, what Boeing is doing is necessary.
Well, why is it necessary?
Well, it's necessary because the way things are done now, when they
use this technology called BPEL to put these services together, it
requires programmers sitting down saying, well, what are your services
in your processes, and where do we connect them, and how do we connect
them?
And they're sort of hardwired.
They make a switchboard, just like the old days of the telephone, when
you had switchboards with plugs and wires.
And so they plug in all these wires, and now they've got connected
processes.
Now, if you look at what companies, the way companies are going,
they're going from just one big enterprise to outsourcing some to
being really fully connected enterprises.
And that means more and more connections.
Now, there was a prediction back in the days of switchboarding of
telephones, when basically they would hire a lot of women to man these
switchboards and connect these things.
And there's a prediction that if telephones kept growing at the rate
that they were growing, by 1950, one-third of all the population would
be employed as switchboard operators.
Fortunately, we got automatic switching.
We don't have automatic switching for these services.
And yet, we're becoming more and more interconnected, and as Boeing
found out, one of the things you'd have to do is to manage change.
Every time something changes here, if you've connected this way, then
the programmers from these three companies, or five companies, or ten
companies, have to get together in a room and figure out how to rewire
the switchboard.
That won't scale.
That's why it's necessary to do something different.
Well, I'm going to talk now about a radical vision.
We don't have to go this far, but I'm going to tell you what's
possible.
And this is my favorite slogan.
The universe doesn't run on workflow.
It runs on physical laws.
So enterprises ought to run on enterprise laws, so you can have
enterprise physics.
It is possible, and there's various ways to do this, to simply state,
what are the laws of the enterprise?
What are all the regulations?
What are the policies?
How should things work?
And then, to dynamically generate the processes that you need to get
something done, when you need them.
That is, you need something done, in that moment, you generate a
process, run the process, get it done, and throw away the process.
If you can do this processes on demand, what you have is enterprise
physics.
Because every time you create a process, every time you create a
process, it must be correct.
It has to obey the laws of the enterprise.
Just like when you throw the ball in the air, it has to come down.
That's the law of gravity for our particular circumstance.
And the particular circumstances of the enterprise determine, what are
the laws of processes?
So you can't make anything go wrong.
In fact, what's great is, as these things change, you don't have to
wait for some programmer to encode it.
As soon as an executive says, this is a new policy, and it's written
down as one of these computable expressions, then the very next time,
the next second, somebody executes a process, that policy is obeyed.
Now, how does this get done?
Well, I'm going to talk to you about a few ways to do it, but there's
one book called, written by C.J.
Date, called What Not How, which talks about how to do this with data
log and relational databases.
If you want to get more technical about how to do this with computer
science, with what's called computable logic, computational logic, you
can read this paper.
Slightly higher level is this talk here on enterprise physics.
So let me give you an example, because that was pretty abstract.
We all need to get reimbursed for our travel expenses inside of
companies and universities.
So every institution has some policies for how you get reimbursed.
So here's some sample policies.
The travel clerk, the guy who takes your request, can reimburse you if
it's under $5,000.
And otherwise, you need to have a manager approve the request, unless
the requester is a manager.
But requesters can't approve themselves.
So you see how these policies work out.
And any time you do need a manager, you need to use the first asked,
the least senior manager, if necessary.
Now, who's a manager and how do you determine seniority?
Well, those are policies of the corporation as well.
It could be that who is a manager is just a file somewhere that
somebody says so-and-so is a manager, maybe decided by the Department
of Human Resources.
Or maybe there's a university policy that anyone who has more than 10
direct reports to them, they're a manager.
Either way, as soon as the policy changes, who is a manager changes,
should change.
Level of seniority, again, that may be decided by number of years in
service, the number of direct reports.
Every time that changes, this definition changes and the process
should change.
So let's take a specific situation.
Jim Franklin is a travel clerk.
Jackie Brown and Kathy Johnson are managers and Kathy is senior to
Jackie.
So an example of a process that's produced automatically.
This is, I want to get reimbursed for $4,000.
So this is the process that results.
These things in MOV are services and these are preconditions.
So a precondition of this service is that I've got an authorized
claim.
Now in this situation, it's possible using computational logic simply
to prove that the claim is authorized because Jim Franklin's a travel
clerk and he's authorized to prove the claim because of that policy.
One of the things that you can do in these processes, by the way, is
you don't have to find the service.
If you can prove the precondition already exists, you don't have to
find a service to produce it.
So in this case, we already know Jim Franklin is authorized to do the
claim.
So we create the claim authorization.
That's a precondition for transferring money from the company bank to
get it ready to give to you.
We have another service that gives us the employee information about
where's my bank.
I'm over in the Spark Plaza.
That's Deutsche Bank.
So the funds are held for transfer.
We get the information here.
Now we can use this service for reimbursing the employee and I get my
travel reimbursement.
So that's how that service will work.
How would it work if I needed $5,000?
It would work just very slightly different.
I wouldn't be able to prove that Jim Franklin could prove my claim.
Then I have to use the service of request claim approval, which would
then go out to the least senior manager.
Now this can go wrong.
One of the nice things about processes is they go wrong.
So what happens if Jackie Brown then, who is the least senior manager,
doesn't approve the process?
Well, you can see what should happen.
The next person qualified to approve the request is Kathy Johnson.
The request then gets approved because Kathy is a little bit more
lenient.
The claim gets approved and the same thing happens.
The process that gets produced is very similar.
It just gets repaired a little bit.
This is the kind of thing that you can do with this sort of more
radical vision, but you can do this.
We academics can do this.
They're not going to do this in an industry anytime soon, but they may
be forced to do something like this sometime soon because managing
processes the way they do it right now is very difficult.
In fact, it really won't scale.
So let me talk about why you would want to do this.
Well, the first thing is that it's a framework.
You remember phones from, I don't know, you're probably too young to
remember phones like this.
So what we have today are these smartphones and they're very flexible.
They come with a framework for apps.
So you want a new app.
You want Bump, so that you can just bump hands with somebody and
transfer your contact information.
Somebody says, I don't know what Bump is.
Well, look for it.
You can download it in less than 60 seconds.
You do that and now you have a new app.
You can't do that with these old phones.
They're hardwired.
They have the features that are built in, no more and no less.
So this is the kind of IT systems we have today.
For these processes.
And this is what we need in the future.
We need something that's flexible, modifiable, and so that when you
modify a policy, the system synthesizes the policy and reacts to it.
Now, one of the advantages of doing it this way is that when you
synthesize the process this way, it's provably correct.
You do it with computational logic, you're actually doing a math
proof.
It's mathematically correct.
So first off, you know it's correct, so you don't have to do any after
the process, you don't have to prove that the process is correct.
That's what's done today.
Programmers write a process and then they go through verification
testing to make sure that the process is correct.
There's no deadlocks, it's safe.
Now the other thing that's problematic with the processes today is you
actually don't know what they do.
When these guys get together and they've got a process from this
company and a process from this company and a process from this
company, and they merge them.
And then they go through the testing process to make sure that this
new process is okay, that it won't result in any deadlocks, for
example.
And then they're done.
They go, glad we're done with that.
They don't know what this process does.
They know that these processes somehow run inside their companies and
they're all linked together.
Not their problem.
They just know that it's not going to cause any problems for the IT
department.
With this, you know what it does.
You give the system a goal and it proves the goal.
And by proving the goal, it generates a process.
And it's mathematically provable that this process will achieve that
goal.
You know exactly what the process does.
So, in general, it's like going from these pre-programmed features to
this general platform.
It has these advantages.
And it works not only for individual departments, but for companies.
So if you have three companies together, and you know what all their
policies are expressed like this, and you say, we need a new process
that does X, you generate a process that incorporates all the policies
from the three companies and it does X.
So, the other problem is, with workflows, is that they're frequently
reworked.
Because the only way that you can change a workflow right now to
respond to changing conditions is somebody's got to reprogram it.
And this leads to error.
I'm going to show you an interesting error.
So, let me give you a very simple supply chain problem.
And you don't have to think too hard about this, because it's too hard
to think about.
I'll just, I'll tell you the answer.
But let me just work through it.
So we got a car company called Sintra.
Sintra puts in an audio-visual console in its car.
And it takes, it's old fashioned, it takes a CD player and it's got to
have a power supply and it's got to have the dispenser for the CD.
So this is back in the old days of CDs.
But it is using a new connection service.
It's kind of like a USB connection except that it's sort of special.
It combines power and control.
Each device has exactly two ports for connecting these things
together.
And any two devices that have been connected by a manufacturer can
only be disconnected by that manufacturer.
Now, in the beginning, this is fine.
You've got a company called Unibus that if you give it any two
components, they will connect them for you.
The car company, Sintra, has a service that can connect any component
to the car chassis.
You've got a shipping service to move things around.
And you've got a company called Car CDs that has the dispenser and
you've got a company called CDs or Us that supplies the CD player and
a power supply, but they're not connected.
The workflow for handling that is obvious.
You can see how the sequence of shipping components around having them
connected would result in them already connected to a chassis.
So it's very easy to work out.
Now, we have a contingency.
It turns out CDs or Us can't deliver the power supplies in time for
the next batch of cars.
So what is Sintra to do?
Ah, there's an opportunity.
There's another company called We CDs and they offer a CD player.
It's already connected to a power supply, but that's okay because you
need both of them, right?
So if you think about what was the workflow here, what do you do to
change the workflow?
What a programmer would typically do is pretty obvious.
You would substitute We CDs or CDs or Us.
They're providing the same components and the only difference is these
are already connected.
So what's really the best new workflow?
The answer is not obvious.
As I said, you don't have to think about it.
But if you think a little bit about how this is done, when we do this
through computational logic, we go through a process that we call
planning.
We start from up there, but it's really what anybody would do.
And then the plan is executed in this direction.
It's planned in this direction.
And the problem is that if you just do that simple substitution I
said, when you get up to this point, you find out that everything is
already connected and there are no free ports left to connect the car
chassis to.
And that means this whole thing's got to be shipped back down here to
let them disconnect at this point.
Whereas a planning system, if you give this problem to one of these
planning systems that synthesizes the process dynamically, it would
automatically start off by disconnecting this connection and then ship
everything around and everything would be perfect.
So that's the difference between synthesizing a process from scratch
and trying to patch a workflow when you have a problem.
And patching workflows is one of the problems that happened at Boeing.
Well, that's a great vision.
And what I'm going to talk about now is you don't have to actually do
this whole vision.
But if you had this, and one day we will have it, you can see another
problem that we do have today.
And the problem we have today is that we've got a lot of connected
systems and then things happen.
So even if you could do what I just said, it just shows up.
What's wrong with it?
Well, the problem is you've got very intricate processes and things go
wrong.
That's a contingency.
As we saw, you can also have opportunities.
At different points in here, you may get conflicts between different
players in the web of work.
You've got humans that mix in and go, no, no, I want it to go this
way, which causes problems.
You have simple failures, like the authorization to approve the travel
request.
And you simply have revisions.
Things get revised.
And then if you try to do revision by patching a workflow, you run
into problems.
So you actually need something more than process synthesis.
And that's actually what I'm talking about today.
Process synthesis was an example.
It shows what we need to do.
But the real thing that's going on overall, when we're talking about
connecting all these companies and people together, is collective
work.
You have multiple actors and multiple objectives.
Now, if you know operations research and integer programming, you know
that, oh, we can solve this.
Just give me a weighting function for all the objectives.
Good luck with that.
You're not going to find an objective weighting function for all the
web of work suppliers to the Boeing Dreamliner.
Now, what you do get, the only thing that you get is Pareto
optimality.
That says if you've got multiple objectives and they've all been
satisfied in a certain way, then it's Pareto optimal if you couldn't
increase the satisfaction of any one objective without decreasing the
satisfaction of some other objective.
That's Pareto optimality.
And there are many stable points like that.
So we can do better than that, though.
I mean, it turns out if you mathematically think about tasks and how
they are connected, you realize that there are a lot of, all these
things, these contingencies, opportunities, conflicts, can be
mathematically structured.
And you realize that what's needed is notification.
So that when there's a contingency and you have to revise something in
your plan, you need to know who does this affect?
When there's an opportunity, you need to know, could I better my
decision?
In fact, one of the things that we can detect is loss of Pareto
optimality.
We can tell you who's involved, what your options are, and who would
be affected by the change.
This is the kind of thing that we need, and this is the kind of thing
that Boeing needed.
You also need help with this replanning and rescheduling, just like
when the travel request was not approved by the first manager, we had
to do a simple replanning.
Well, overall, managing these things is the coordination of collective
work.
So this affects all kinds of groups.
One of my favorite targets for talking about this is car
manufacturers.
Now this over here is a joke.
Ikea buys General Motors and gives you your car as a kit, and they
give you one of those little Allen wrenches which you can put your car
together with.
But really, cars are put together by a lot of suppliers now.
They're very complicated.
It used to be, say, ten years ago, new cars were designed and it took
a day to integrate all the parts.
Now it can take weeks, and it's not done right, still, because of all
the dependencies among all the parts and all the players.
In the future, it gets even better.
You won't have a car manufacturer that has a plant.
You have a car manufacturer that manages processes.
So the car manufacturer then will be Dell Auto, and they will have
chassis made in Shanghai, assembled in Mexico City, and shipped to
Engines R Us in Stuttgart.
And the opportunity comes up, oh, there's a new Tasmanian company, and
they can do the next 20 chassis cheaper and faster.
And the question is, if you have this kind of situation, who needs to
be notified of what?
This is the notifications I was talking about in the last slide.
So in this case, we have to revise the supply chain.
We have to notify, maybe using web services, that chassis Max and
Simmel now are respectively canceling and placing orders, that the
finance department has to be told that the deposit that they had on
file with the Bank of Mexico, because the chassis were assembled in
Mexico, is no longer required.
The treasurer needs to know that a scheduled transfer of funds should
be canceled.
And the order department needs to be notified that there's a PO to be
sent.
All this should be automatic.
And what should not happen is engines are us, and Stuttgart should not
be notified, because the same parts are going to arrive at the same
time, so they don't need to know.
So all that should happen automatically.
Not with pre-programmed notifications.
It shouldn't be the case that somebody sat down and said, what if?
Because you'll never anticipate all the what if conditions.
People try all the time, and again, it causes the problems that Boeing
had.
It should be automatic.
Just like the framework for the apps and the phone.
So the upshot is that we've got this interoperable network.
We can connect everybody to everybody, but all we're doing with it
right now is sharing information.
I decide to share information with you, you decide to share
information with me, but we each have to decide to share, and we have
to know to share.
And instead, the network could be active.
It could be supporting us.
So some other examples are, if you go to the large construction
project, there'll be a general contractor, subcontractors, architects,
inspectors, whatever, and they make a plan.
They make a plan using the critical path method, CPM method.
Two weeks after the project starts, that plan is obsolete, because of
all the changes that have happened, because there's no system that
automatically notifies people.
Instead, the general contractor has a bulletin board in his office,
and you can go into any contractor's office and see this bulletin
board.
It'll have about a maximum of 200 post-its on it, because that's the
number of post-its anybody can manage, and it will say, gee, the
architect moved the stairwell.
We have to change the date for the concrete pouring and put off the
inspection one week.
If you're building the new space station, it turns out that the
docking bay gets changed, and that turns out to impact the design
that's been put up for insulation by the thermal engineer.
In your corporation, you're planning a meeting on how to do the audit,
but you just decided to outsource that task.
Who's going to remember to cancel the meeting?
It should happen automatically.
Your garage just reported that your repairs are done more quickly than
you anticipated.
Your friend should get an SMS automatically that you don't need a ride
anymore.
Boeing, the wing fastener, all that should happen automatically.
There's a way to do this.
This is a way to do it.
This is not the way to do it, but this is a way that we've tested out
in concurrent engineering.
There is a model of design that you can mathematically construct.
You know what a decision is.
A decision is something that takes a goal, and the output of a
decision when you have a decision is either or some set of statements
about the design or some new goals, the sub-goals.
A goal is satisfied when it only produces statements or all of its sub
-goals are satisfied.
In this case, this goal is satisfied because there are no sub-goals.
This goal is satisfied because there are no sub-goals, and that means
this goal is satisfied because its two sub-goals are satisfied.
Thus, this goal is satisfied.
Ah, but this statement is in conflict with this statement.
We have a constraint violation, which you can decide to fix at any one
time.
What happens when you do this?
Well, one of these guys has to change their decision.
And what can happen is suppose this guy changes his decision and this
sub -goal is no longer needed.
The guy who is working on this should be told, hey, what you are doing
is no longer valid.
These parts are redundant.
Get rid of them.
And by the way, if this guy changes his decision, this guy should be
told, hey, you could go back here because you no longer have a
conflict.
This kind of thing can be worked out mathematically.
These notifications can be sent automatically.
And we've experimented with this in a system that was called NextLink,
where we... I'll show you an example where we design things.
We have a coordination manager that uses this model.
We have a plan manager, a constraint manager.
And these are generic, domain independent.
And then over here we have some domain specific agents that interact.
And so, for example, somebody is designing a pick-up head for a new
DVD player.
And in this example, what they've done is they've decided to design
their own optical pick-up head.
And they're going to do it from scratch.
They're going to build all the components for it.
And so that's been the design decision.
They have some statements about it.
And then that means that if you look over at the concurrent plan to
build this thing, that if you're going to build a support for that, it
has to follow the actual construction of this, because you don't know
how much this weighs until you've built it.
And you don't know how much you have to support until you know the
weight.
So that's a logical consequence.
However, the designer on the other side, on his tools, makes a design
decision.
He gets rid of this decision.
He makes a new decision.
And the new decision says, I'm going to use an off the shelf
component.
It's just too much trouble to design the thing from scratch.
Well, that means that this sub-goal here is redundant.
So the guy designing some other part should be told, you don't have to
do that anymore.
And we know the weight of the component automatically.
It's in the specifications for the off the shelf component.
That means the plan automatically can be optimized.
You can move this task back, because you already know the weight of
the pickup hit.
That's the kind of thing we can show can be done using these methods.
So, you can actually work out various steps, say using service
-oriented architecture, real service-oriented architecture.
What has to be done?
What are the technologies that have to be developed to get to first
dynamic processes, and then fully, full process synthesis, full
management of these processes and all the changes that can occur.
Does anybody recognize this mountain?
It's my favorite mountain.
It's the Vatzman.
Too young.
Okay.
So, but you can have, oh, here it is, right here.
There's the Vatzman.
All right.
So we can do this, technically.
But there are a lot of fundamental questions that have to be answered.
Now, one of them is, again, back on semantics, is how do we make
semantics simple?
And a lot of people are working on this right now.
We're working on here at the KIT some alternative ways of doing
semantics.
And one of them involves making people feel like they're part of a
collective effort.
So, they're doing something that's in their own interest and
contributing to something that's bigger than themselves, just like the
World Wide Web.
Whoever thought that everybody would start putting up web pages for
free?
Nobody's paying you to put up web pages.
How did that happen?
Inside of industries, there's the notion of industrial service parks,
where semantics could arise just because it's good for the company and
the customers.
So, there's some things that could happen.
And we're working on some of them.
There's some specific challenges for specific organizations.
If you're the EU or in the States, the NIST, National Institute for
Standards Technology, you could reward people for developing
interoperable semantics.
If you're a developer, if you think you've got some interoperable
semantics, you could test them on something that we ran for about five
years called the Semantic Web Service Challenge, which showed that it
was much harder to do this than anybody thought.
There are these people who call themselves service-oriented
architects.
Well, can they do better than CRUD?
CRUD is create, read, update, delete.
So, one of the things that they do when they say, I've got a service
-oriented architecture.
Our stuff is composed of services.
All they do is they take some little CRUD services.
How do you create, update, read, delete a business object?
And they make a WSDL service for it.
And they say, oh, we've got a service architecture.
That's not it.
The other thing they do is they take a whole complex process and they
wrap it with WSDL, automatically generated WSDL, which is 35 pages of
machine -generated code.
And they say, oh, look, we have a service, which no one could possibly
use.
We are working on some of these problems here at the KIT, the KSRI.
If you're a customer of one of these companies, it would be nice if
you demanded that they give you real SOA.
Entrepreneurs, ah, there's something called Worldwide Workflow, which
we're also working on here.
And that is sort of Amazon's Mechanical Turk on steroids.
I don't know if you've ever looked at Amazon's Mechanical Turk, but
this is sort of what's also called an IBM parlor.
It's PeopleCloud.
It's the idea that you've got some small tasks to do.
You need a word translated.
And you throw it out there and you say, I'll pay you two cents to
translate this word.
And somebody takes that task, they do it, and they get paid.
Well, you can do it with bigger tasks.
And again, this is in the future, where you're going to have everybody
in the world is already connected.
So why not let everybody work together all the time?
What we need is some way to coordinate them.
The reason these are micro-tasks is there's no way to coordinate
people on bigger tasks, where you have subtasks that interconnect.
So you generate something called the Worldwide Workflow.
And so you can get this on your cell phone, you can get it on the web,
and it says, here's your current task, here was the previous step,
here's the next step.
You bid on it, you're going to get paid as soon as you complete it,
and you do your part of the task, and then we'll tell the next person
what their task is.
And then you can do bigger tasks like this.
So that's the next step that you'll see on the internet.
So that's the next step.
After you do that, then you have perhaps these workflows being
automatically generated with something like the system that I just
told you about and coordinated with the more advanced notices.
So, there are unsolved problems.
I call all this coordination engineering.
It doesn't exist yet as a field, you can't take a course in it, but it
should exist.
Because we do have some unsolved problems.
What I've just given you are some existence proofs that something like
this could be done, but these existence proofs don't solve these
problems.
For instance, in the supply chains, when something happens three
suppliers down the road, they're late, and the end supplier needs to
know, you don't want that information passed all the way up the chain
because the people in the middle are competitors, and they shouldn't
know that this guy's having a problem.
So, how transparent should the information be?
Who can see it, and who can't?
And how do you protect it from the people who shouldn't be able to see
it?
Can we do simulations of change?
Can we do domain specific filtering of these notifications?
And so on and so forth.
There's all kinds of problems which I could go into about, and these
are nice theoretical problems.
They're good topics for academic research.
The point is, this is a new field of research.
It needs to be done.
There's a lot of work to be done in it.
Now, what are the general principles?
Well, suppose that we could elaborate what these general principles
are, how everything works together, solve all these problems.
What would we have?
Well, we'd have this coordination.
Now this coordination results in lots and lots of messages.
You get lots and lots of messages in your head every day.
Somehow you prioritize them.
You know what to pay attention to.
Now companies are going to have to know what to pay attention to.
Now we know something about prioritization, but these companies are
going to have to do this.
So the company is going to look like your brain.
It's going to look like it's getting lots and lots of messages, and
some part of your brain is going to have to decide what to pay
attention to.
Right now the CEO does that.
The CEO pays attention and says, we should not be looking at the price
of travel.
That's a trivial cost in comparison to the cost of our overlapping
projects, or vice versa.
He makes that decision.
So the idea is, can you automate that kind of decision making?
Well, of course you can.
So now you've got a conscious organization.
It's just like you are.
You're deciding what to pay attention to, almost automatically.
We know how to program priorities.
We know how to learn them.
So you get this, and now you've got something like Marvin Minsky's
Society of Minds, where you've got all these components, there's all
these messages going around, and you're prioritizing what you pay
attention to.
Some of these agents are people, some of them are us, some of them are
machine software, and they're all producing messages.
But now the system's adaptive.
People talk about innovative corporations.
Well, that's an oxymoron.
Corporations today are built to do one thing efficiently.
They don't want to adapt, but they have to adapt in the future.
And now you would have an organization that was actually adaptive.
So this is the Internet...
So this is your Internet of your future.
It's based upon the old one, but there's a lot of new uses.
So feel at home.