ARCast.net - SOA from Theory to Practice

Announcer: It's Tuesday, May 22nd, 2007 and you're watching ARCast TV.
Ron Jacobs: Hey, welcome back to ARCast TV. This is your host, Ron Jacobs, and today we are going to go back to Tel Aviv where we're going to speak to Izak Cohen and Eliaz Tobias, a couple of my colleagues from Microsoft Israel who have been thinking about the Enterprise Service Bus. Now, ESB has kind of become a popular idea and I totally get why it's a popular idea, it sounds really good to create a bus that services can hang up but a lot of people have said, "Well hey, Microsoft doesn't have an Enterprise Service Bus." I mean, where do you get that? What Izak and Eliaz have done is they've taken some ideas in technology and put it together to make the concept of Enterprise Service Bus come alive. Let's see how they did that.

Hey, this is Ron Jacobs and I'm here in Tel Aviv, Israel which is -- this is a beautiful place except for that I brought the rain with me. You would think it wouldn't be raining but here in Israel it's raining today, nice and gloomy. I arranged for this especially, you know, so that I'd feel comfortable here in Israel, but today I'm joined by Eliaz and Izak. Did I say that right?
Izak Cohen: Yes.
Ron: Yeah? OK.
Izak: This is Izak, yes.
Ron: OK, good. I'm always nervous about names now. Ever since I mess up people's names and then they always tell me afterwards, "You've really messed up my name on ARCast!" [laughs]

[laughter]
Ron: But anyway, the names are beside the point. OK guys, introduce yourselves and tell me a little bit about what you do. Let's start with Izak.
Izak: OK. I'm Izak Cohen, I'm the technology solution professional here in Microsoft Israel. I'm running the process platform, so that means that I have the BizTalk server and with the BizTalk server we go into the ESB. It's issuing, we've come to spread the rumor!
Ron: Ah OK... [laughs] Now, that's a lot of TLA -- that's how I say three-letter acronyms for BizTalk, ESB and all that...
Eliaz Tobias: BizTalk is seven letters.
Ron: True, it is --
Eliaz: But we have BTS.
Ron: But we have the BTS, the SOA and the ESB; all in one. OK... [laughs] All right, so --
Izak: We'll try to explain it in the session.
Ron: OK, OK, cool and Eliaz?
Eliaz: Yes. Hi Ron, my name is Eliaz and I'm the architect evangelist here in Israel. Mostly I work with architects around SOA software factories. Many concepts, and this is why me and Izak are starting to work together because SOA is about architecture and it's about infrastructure too so we kind of find ourselves working out together on this.
Ron: OK, all right. So, I like what you guys were talking about, you're doing a session at this event we're having here in Israel. You're talking about moving SOA kind of from theory into practice. To give an example, you've created this scenario. Tell me a little about this scenario that you have, this fictional hospital.
Eliaz: OK. I play the R&D manager in this fictional hospital and Izak plays the infrastructure guy.
Ron: OK.
Eliaz: We're both sitting down in 2007, trying to think how we can address the complexity in the organization with the IT, and we find out like everyone that SOA is probably the solution for most of our problems. This is why we go together to try to understand what message we need to bring into the organization from the architecture and from the infrastructure, together.
Ron: OK.
Izak: I think that when we are dividing the old problem, the problem of the complexity to two areas; the area of the architectural and the area of the infrastructure, it's easier to "chew it," it's easier to make some kind of infrastructure to the organization. Then, when you have the infrastructure, you can take all the business issues that you want to do and build it upon it and then this is where Eliaz has come into the picture and trying to do his stuff.
Ron: OK, so let me ask you a little bit about the infrastructure for SOA because a lot of people say, "SOA? That's web services, right? So all I have to do is write a few web services. What do you need for that?" A little IS server -- maybe that's it, but is there more? What are you talking about for infrastructure?
Izak: The infrastructure is not just web service. This is a common myth about the SOA. I use the ESB, the Enterprise Service Bus. The Enterprise Service Bus, this is our infrastructure that give us a lot of services that is not business services, it's more like intelligent routing. When I want to take one message and put it in several end points but I don't know what is the end point when I started all the process, that means that I have to do some kind of dynamic routing in runtime.
Ron: OK.
Izak: This is one capability that infrastructure will give you.
Ron: OK, so let's talk about an example from the hospital for intelligent routing. Why would a hospital need something like that?
Izak: OK. Let's assume that you're a patient in the hospital. When the doctor is writing you the discharge paper to discharge from the hospital, use the doctor system. But the doctor himself doesn't release you from the hospital. The nurse will release you from the hospital. That means that the discharge paper that the doctor is writing have to go to the nurse so she can collect it and release you. That means that I have to put two separate systems and sending from one system to another system, the paper.

This is very cool when you are inside the hospital but let's assume that you have the doctor -- the personal doctor of this patient -- that he's out of the hospital. He is sitting in his chair and want to get also this paper but is not in the system.

That means that we have to connect him in some way to the system. We will connect him to the ESB and he will come and say, "Hello, I'm the personal doctor. I have my system. I want to get the discharge paper from the hospital."

But the hospital doesn't know in the beginning that they will have to send this paper to the doctor. So what are we doing? We're using the dynamic routing and the dynamic routing, the ESB is --
Ron: [laughs] OK.

[laughter]
Izak: Take two...
Ron: [laughs]
Izak: Give me one minute? [speaks in own tongue] Register. Sorry.
Ron: OK. Ready? Three, two, one, rolling...
Izak: OK. The personal doctor system will register to the ESB with some kind of profile. This profile is similar to the profile of the nurse system. That means that when the discharge paper will go from this doctor system in the hospital, it will go both to the nurse system and to the personal doctor system because the metadata of the paper can see that he will have to go to both places.
Ron: So really this sounds almost like it's easy for me to think about this if we were talking about sending a message to a person, we would send them an email, right? And so I could say the doctor system -- if I'm the doctor, I'm discharging the patient, we put in there who the nurse is, who the guy's personal doctor is and we say, "I'm discharging him" and the system sends them an email. As for people, that works pretty well.

But what you're saying is the ESB would allow us then to send the message to the application that that doctor, that nurse, is using.
Izak: Right.
Ron: And that we might not know exactly what the end point of that system is until they log in and dynamically register and say, "I'd like to know about when that patient gets discharged." So you have an actual infrastructure that you want to put in place that allows the system to say when a discharge patient event happens and it's this particular patient. We need to know that that nurse's system know and this doctor's system know.
Izak: Right and it's all in runtime. You don't have to shut down the system to add the new doctor. You don't have to change the code. You just plug in to the system.
Eliaz: Like a bus actually. It's like a real bus in the traffic and people get on to it on runtime. You can think of it like this because in the past, we needed to add these functionalities to the ESB that Microsoft had. But now we have an ESB that really gives you the capabilities and true runtime, like automatic subscription, dynamic routing and many other capabilities that we provide.
Ron: OK, I can just hear that some people out there are going: "Wait a minute, wait a minute! Did Microsoft create a new product that [laughs]... what are you talking about? That does all this? Where can I get it? What is it that we're talking about?"
Izak: OK, we're talking not a new product. We're talking about a solution, this solution called the ESB toolkit. It's based on the BizTalk Server 2006 and.NET Framework 3.0. Let me tell you, Ron, a lot of people that hear it will say: "Oh gosh, we write it two years ago!" It's not new. But the new it's not that we have a new product. We have the solution that is ready for you. Just don't go to your sites and start to develop this infrastructure because this is what happened in a lot of places.

People are building this kind of capabilities. We'll bring it to you. This is a solution. It's here, it's working and projects that use it. That's spectacular, it's very good.
Ron: And how much does this cost?
Izak: Oops.

[laughter]
Izak: We don't know.
Ron: I mean, is the ESB toolkit, is it something...
Eliaz: We're not sales guys.
Ron: Is it something that you have to pay for extra?
Izak: I don't know for now because for now this is very new. In the beginning we're not charging any money for it in the test field project, but I don't know what will be the...
Ron: Oh, OK.
Izak: ...how it will come on.
Ron: So I didn't know if there was, like a free download or you just go get it in the ad[?] somewhere.
Eliaz: Now it's ready for partners mostly.
Ron: OK.
Eliaz: What we did is take an implementation that Microsoft did in Kaiser Permanente and it's one of the largest ESB implementations that we did. And we took the generic parts of this implementation and gave it as the ESB toolkit.

But it's not like we didn't have any ESB before. We had an ESB developed in Israel for example, in the Phoenix Insurance Company. It is one of the best implementations with management and a lot of capabilities that regular ESBs today provide. And it's not...
Izak: And it started in 2004, it's not new.
Eliaz: It's not like we couldn't provide it. We had the infrastructure even before, but now we are even closer because most of the other capabilities are also inside the solution. So now the solution is more complete and more appropriate to the ESB definition.
Ron: OK. I like the idea of the ESB, I understand that this is something that is just by adding some things to what we already had in Biztalk servers.
Eliaz: It's wrapped. It's just a wrapped call that we give.
Ron: OK, so aside from this intelligent routing, what other kind of infrastructure services do you need for this ESB functionality?
Eliaz: That's exactly what I asked him because I did not want to put this ESB in the hospital. I wanted to know what are the other capabilities that it might provide us.
Izak: I will use the..

[laughter]
Izak: OK, no problem.
Ron: OK.
Izak: Let's use the scenario that we talked about it. You remember, I had the doctor system.
Ron: Yeah.
Izak: And the doctor system had to send the discharge paper to the nurse and to the personal doctor outside of the hospital.
Ron: OK.
Izak: Every system is working in a different platform. Every system is keeping the message in other ways. That's mean that you have to make some kind of transformation on the data. We have the dynamic routing that know where to send. Now we have also the dynamic transformation that is going in runtime to the registry and asks the registry: I have to take this paper, I have to move it to the nurse.

What is the map, what is the transformation that I have to do? OK, give it to me. On runtime, it take the transformation and change the data and send it to the nurse. The same thing is happening to the personal doctor. Also, what is the transformation for the personal doctor? Give it to me, I will translate it and send it to the doctor.

That mean that one message came out of one system, translated to two separate type of data and sent and everything is dynamic. Everything is on runtime.
Eliaz: You don't have to plug off your systems in the hospital in order to put these new changes. For me as an R&D, when I develop new capabilities to be added to the workflows, to be added as more transformations, it's important that Izak will be able to put them. In production time we doubt lowering down the systems, this is an important feature that we have now with the ESB, with the ESB toolkit.
Ron: Ah, OK. all right, so then we can say, hey, this doctor system needs a message in a certain format. When they register, we can create a message map that says when I need to send a message to them, it has to go in this way.
Izak: Right.
Ron: Well of course, in hospitals they often have to send messages to many different kinds of insurance companies and pharmacies and labs and a lot of different partnerships they have. It seems like it makes a lot of sense.
Izak: It makes a lot of sense because you always get the new system into the... that you want to work with them. And a lot of the time, it's outside the hospital. Because you know you have a new doctor on the road, you have a new system, let's say a brand new system to fix the eye with laser, so you want to talk with her.

How will you talk to her, with her? You can talk to her because she will register to the bus, she will enter it to herself. How? I have this meta data that's mean that I need this type of transformation, I can do this and that. And all of it is in runtime. This is the great thing.
Ron: OK, but what about -- big question -- security?
Eliaz: Oh.
Ron: How do we address security in this situation?
Eliaz: WS security. All these web services standards are implemented already in the ESB. And not just security, transactivity, reliable messaging, all these WS star standards are implemented by the ESB. There's no problem there. We're compatible to every other vendor also.
Ron: You know, that's amazing, isn't it. Because you...

[laughter]
Ron: ...talk about just a few years ago, this was a big headache. Anytime we try to hook up somebody outside, now it's a lot, lot better. OK, so... all right. What you are talking about is establishing an infrastructural platform with this intelligent routing, with this dynamic message mapping capabilities, security's all baked in - great. And now we've got to add some services that actually do something.

[laughter]
Ron: So Mr. Architect...
Eliaz: Thank you.
Ron: What kind of services, how do we think about getting the services we need?
Eliaz: First of all I want to tell you, Ron, that I envy Izak. But I will use your ESB [inaudible].
Izak: Oh thank you, thank you.
Eliaz: Because it gives me a more infrastructure services for the R&D, the routing, the management, the registry, that's great. And the workflow. Everything that it gives, I will use. However, in order to really get the main value out of SOA, which is more than just an ESB, in order to gain the agility our organization is looking for, we need to do more than this.

I'm looking at -- don't get offended, Izak -- but I'm looking at the ESB as something that is, actually, if you satisfy with this it's like putting lipstick on the pig's face.
Izak: He's always calling me a pig. Always.

[laughter]
Eliaz: Your system. Not you. And I'm thinking about getting out those functional services, those functional capabilities outside of the system in order to be able to re-use them. And those functional capabilities are logic, they are code that was developed in Cobol, in C#, in Java, and some of them can be exposed and this is why we need a more practical approach to build those functional services, in addition to the infrastructure services that Izak referred to.

The main message that Microsoft provides here also is the middle road approach. And the middle road approach is an approach that provides the ROI to the decision makers in shorter cycles.

Why? Most of the SOA projects are something that starts as a big project and they last for years. By the time the management sees any ROI from it, they kind of lose faith in the project. And this is why most of the projects fail.

So what we suggest here is trying to address a business need every time. And after you address a business need, expose the capabilities as services that address this business need. And then compose them into a process. And then consume them from all kinds of clients. Not just portal, because Microsoft is strong in the client side, too.

So we can consume it from mobile devices from SaaS based applications, from Web 2.0 applications, from composite applications, from every kind of client--and that's the main goal.

What's important here is that we're able to provide agility to the organization quick, because we don't need to address every business need at the beginning.
Ron: OK, so let me ask you about agility.
Eliaz: OK.

[laughter]
Ron: This is like one of those words that...
Eliaz: It's more than a three letter...
Ron: Well, every time when I heard people say "agility," you know what, I pictured in my mind? I pictured like a gymnast, who's doing flips on the mat.

[laughter]
Ron: There's somebody who's really agile. I mean they can move quickly, they can leap over things, and flip around in the air. It's a fantastic... I'm trying to imagine what an organization that's not agile look like? Then I picture some rather large person, who can barely get off the ground.

[laughter]
Ron: Trudging along on the mat trying to do these things, and they can't do it. Wouldn't you see an organization that's not agile--OK--what are the symptoms of that? How does it look from the inside of the IT organization there? What kind of things do you see?
Eliaz: The IT is just not responsive enough, or the CEOs that gives those business needs. The market...
Ron: So, that would be like the CEO says, "Hey, we've got a business opportunity here. If we can make a deal here with this external partner we could save 20% on our costs." The IT says, "Oh, that will take us two years to get that done."

[laughter]
Izak: The stores came out after the 9/11 they sell flags. Because they was very agile to buy the flags into the store, and spread them out to the people, they now the biggest network in the US. This is agile for a business.

If you can know what happen now in the market, and you can react it in short time--that mean you can catch the train, you can make money. Because let's face it, technology is tremendous. I love technology, I am a technologies man. The business must do money.
Ron: [laughs]
Izak: They want to do a lot of money!
Ron: Yeah, OK.
Izak: If it's agile, it can do a lot of money. It can become the leader among it's competitors. This is agile.
Ron: All right, so if you had this kind of infrastructure in place, like you were talking about, and the CEO says, "I need to have this new partnership in place very quickly." You can do it?
Eliaz: It's easy, because you're just composing. It's like a Lego - you're not building a system from scratch. When I was working 10 years from now as a developer, I developed everything by myself. I was also not connected to the Internet, so I couldn't even look for anybody.
Ron: [laughs]
Eliaz: But even if I was, the main way people worked in the past is by building on their own, and not searching. Today, development is more like searching for reusable capabilities inside organization, or outside of them.

So, because all we need to do is compose, and not build from scratch. We have great tools for this like, designers, SOA designers, wardrobe designers, music orchestration designers--all these software factories that Microsoft is talking about.

This is why it's easy for us to be able to provide the agility that the organization needs. If the CEO wants something for an hour from now we can provide it, because we just need to hook things up.
Ron: [laughs]
Eliaz: I know it sounds... This is the vision.
Ron: Yeah.
Eliaz: ...most of the organizations are not there. What we're trying to do, and we do this in a session style, we're trying to imagine how the organization, how the hospital, would like in 2010.

When the CEO calls us, and tell us that for example HMO wants to buy our hospital. So what we're doing is, we're able to hear his request, and continue to play games, what we're doing in this presentation.
Ron: [laughs]
Eliaz: And then we'll say OK. An hour before we leave work we'll hook things up, and be able to provide those capabilities that the manager needs. So, this is the way we try to visualize, and to say to the CEOs and to managers what SOA can give them. So, it's a means, it's not a go--and this is an important thing.

Most of our customers, even here in Israel, are looking for SOA because of the sake of SOA. They are not looking for SOA as something--maybe they are--but they're not doing it.
Izak: I've been with a customer. We're sitting around the table, and I asked him, "OK, what do you need?" "I need an ESB." "OK. Why do you need an ESB?" "I don't know, but I need an ESB."
Ron: [laughs]
Izak: "What will you do with it? I will bring you an ESB. OK, what will you do?" "I don't know. But the manager told me, 'You have to bring an infrastructure, an ESB, to the organization.'" This is a lot of organizations, this is not just one, and I'm not kidding--that's realistic.
Ron: Yeah--I'm sure.
Izak: So the problem is to show them the value, what they can do with it--why do they need it? Eliaz is talking from the business side, and I'm talking from the infrastructure side. Together we can combine this agility to the organization, and bring him to the next stage.
Eliaz: ESB is like an enabler, or SOA, as well as web services are an enabler of SOA. SOA is an enabler to other great things like, SaaS, like Web 2.0, like agility.

SOA is actually like the elephant in the story of the elephant and the six blind Indonesian that go through the jungle and bump into it, and what they are trying to say to each other is here. They don't know that they bumped into an elephant. One of them thinks it's a wall, one of them thinks it's actually a snake, one of them thinks it's a rope, and they're trying to struggle who's right. They are all wrong, but they are all right, also, because they see different parts, different viewpoints of this elephant.

This is why me and Izak, we see SOA from different parts. I see it from the architecture, from the R&D side, and he sees it from the infrastructure side. But, I think that the important thing is, that we're trying to work together on this to address customers, because they are looking for both things. They need both things in order...
Izak: Together we see the whole picture. Together we see the whole elephant.
Ron: Aha!
Izak: And this is the issue.
Eliaz: Tell them about your marriage.
Izak: About my marriage?
Eliaz: Yes. [laughs]
Izak: Oh, gosh! You always raise it.
Ron: [laughs]
Izak: OK, I will tell you about my marriage. [inaudible] I met my wife 20 years ago.
Eliaz: [inaudible]
Izak: It was in the kindergarten.

[laughter]
Izak: When we started to meet each other there was a romance--as you know a meal with candles, music in the air, and everything was glowing. But you know after 20 years, when you're trying to see what you passed in all these years, you know that it wasn't easy. In the start, you're the animal--the love. We also have love today, but it's not the same.
Eliaz: I will stop you here.
Izak: You will stop me here?
Eliaz: I will stop you there.
Ron: [laughs]
Izak: You asked me--you asked me to tell about it!
Eliaz: It's not just about love. I will try...
Ron: [laughs] It's a beautiful thing.
Izak: It's a beautiful thing.

[laughter]
Izak: I love my wife! I love my wife!
Eliaz: What Izak is trying to say, that after the honeymoon stage, he came with his wife to a stage where they have to work together in order for this to work out--in order for the marriage to work out.

This is exactly where SOA is today, even if you look at the hype curve of a gardener. SOA is at the stage that is after this honeymoon stage. Now, if you do this middle-out approach that I talked about, and put things one step at a time. Get the commitment of the management, all those things, then SOA can work like marriage can work.
Ron: OK, let me ask you...
Izak: You have to understand that you will have difficulties in the way. You will have ups and downs in the way, but if you will stick to it--in the end--it's good!
Ron: Aha! All right. Let me ask you about this middle out idea.
Eliaz: Yes.
Ron: Now, so some organizations approach this top-down.
Eliaz: Yes.
Ron: The CEO comes back and says, "We're going to this away, and tell everybody what to do." So, sometimes that just doesn't work very well in many cases. Then I guess bottom-up is sort of the developers go, "I'm going to create some services, and I create my crazy services for whatever I'm doing."
Eliaz: I've read what they have, yes.
Ron: Yeah and then they don't tell anybody. I'll do whatever I'm going to do. In that case you have kind of like a wild growth of services throughout the organization but no management or no strategy around it. What does middle out look like?
Eliaz: Middle out looks like you start with finding out the business drivers and you prioritize them. This is something you can do with the methodology. You know it, its motion, or other methodologies that you are asking the organization -- you're asking the organization's CEO and all the board -- you're asking them questions about the capabilities of their organization. From these details you are able to build a map of the business drivers.

After you do this, you're kind of starting to look where in every stage you're addressing one business need and for this business need you're going through a cycle of three points.

First one is the exposition, the expose. Exposing those services that are hidden inside the existing systems or building new systems in so style that are exposed as web services. Using the service factory, for example, that the patterns and practices provided. After you do this and this is the hardest stage because this requires architecture, this requires the architect to understand where the capabilities, where those functionalities are in the existing systems.

After you do this, you're going through this Lego style -- you're going to the second stage of the compose. Compose is kind of easy after you did the expose of those services.

The last thing is the consume, the third stage. The consume is being able to use, to reuse this composed service; to reuse it for many different clients. After you build it in the backend, it's easy to consume it because Microsoft plant technologies are consuming web services from the first day they were born.

So this is the end of the first cycle and then you continue to do it again and again with new business drivers. Then after a long time -- no, it's not after a long time. After a few iterations, you are able to show the managers the ROI of it.

Even after the first iteration because you addressed the first business need. This is the beauty of the methodology. It's as simple as that, but most organizations are not doing it. They are approaching it from top down or from bottom up and this is why 98 percent are failing to realize the SOA value.
Ron: Yeah, you know the interesting thing about this is when you think about -- if you can just save a little bit of time on some business process that happens a lot, you can save a lot of money in the organization. Just to give a crazy example, the other day I ran across this tool that we have inside Microsoft. Like a lot of organizations, one big problem at Microsoft is booking a conference room.

[laughter]
Ron: You want to have a meeting, you're trying to find a conference room and it's just -- sometimes it's very difficult to find an open conference room. So these guys in Microsoft IT created this website and you just say what building you want to meet in, it shows you all the conference rooms and what's available, what their schedule is and it's pretty quick, you know?

I can't believe it took me this -- how many years I've been in Microsoft? Seven years. It took me this long to find this tool. I don't know how long --
Eliaz: Send it to us because we need it too!

[laughter]
Ron: I don't know how long they've had it but they did a little calculation on their website. They showed that they estimated the amount of time it saved every time someone needs to book a conference room. It's not a lot, it's something less than a minute, but then they talked about --
Izak: But multiplied it by the hour?
Ron: Yeah, multiplied by how many times people book conference rooms --
Eliaz: And how many conference rooms...
Ron: And how many conference rooms there are. They estimate it saves Microsoft $10 million a year to have this little crazy little web act to do that. That's pretty amazing!
Izak: And the developer that made it got the 10 million?

[laughter]
Ron: I wish it worked that way, right? [laughs]
Eliaz: I think they were modest, it saves a lot more.
Ron: [laughs] Yeah! Well, so I'm thinking of -- did you try to imagine some scenarios maybe where the hospital had a business driver, how does expose, compose, consume process works for the hospital?
Eliaz: Yes. Yes, we did. If we prioritize those business needs, the first business need that the hospital does is treat the patient. This is the most important thing. And to treat patient is actually starting with the doctor that gives the prescription.
Ron: Oh I thought bill the patient was the most important thing...

[laughter]
Eliaz: This is the last stage. Yes, this is the last stage. Yes, yes.
Ron: OK.
Eliaz: But this is not a -- Yes, this is a business need but it's not a composed service, you just --
Ron: OK.
Eliaz: I hope, if it's not that complicated. After you give a prescription, you order. The nurse orders the medication from the pharmacy. The pharmacy gives them, supplies them and then you bill the -- you add extra to the patient's bill. This is in our example also, the first business need. We expose those small services that are not really services at first. Some of them need to be built from scratch. Some of them are exposed, some of them are combined from existing systems.

Then you go to the second stage and you're just composing them and use the ESB as the router. The dynamic routing is getting into it, the work flow; everything, and it's consuming those small services through this composed service of treating the patient. Then you are able to free the patient from all different kinds of clients, from the doctor's station -- from the doctor's tablet PC, from its station at the HMO, from the nurse station if all the tablets are used.

You can consume this web service that is registered on the ESB through all different kinds of clients so --
Izak: Even from home.
Eliaz: Even from home.
Izak: From his mobile. Because this is one of the levels of -- consume from the mobile. Don't stick only to the area of the hospital because you know, the doctors get in and out the hospital. You don't want to stick only to the system inside the hospital. This is having money because the doctor doesn't have to go from his home and then the car and drive to the hospital. In the meantime, nothing happens. This shortens the time of the treatment and you get healthier patients and then you can build your next one.

[laughter]
Eliaz: Yes, you'll see the ROI after just the first iteration and that's --
Ron: You know it's quite a change of the mindset, right? It used to be that people said, "Well, you know, we have to build the whole thing." We have to build the mobile clinic for the doctor, we have to build all of these systems all at once, or go buy it from somebody, and this is when you've go into these multi-year, very expensive projects, long timelines, that are very, very risky because you get two or three years into it and they find out, oh it's not going to work or this is not acceptable and people get fired. It's such an ugly situation.
Izak: Oh the system is changed because when you start to develop this system, after three years maybe your needs are different. So a lot of the time what happens is when you deliver the system it's not effective because you work in a different way, you have a different system around. You want to be able to develop a -- to provide your needs to the hospital in a short time so you know what is the area and with whom you're working to.
Eliaz: The middle out approach gives you exit points and in every exit point you can reprioritize your business needs and that's the important thing about it. I agree with you, it's not that easy. It's a change of mindset, it's thinking about what you have and what you need and this is why you need architects so -- this is their role! We need to finish up with this.

[laughter]
Izak: OK, yes, we need architects, don't worry.
Eliaz: And we need IT...
Ron: We need both sides to get the whole picture. Otherwise, we'll never understand this elephant.
Izak: Right.
Eliaz: Exactly.
Ron: Wow, thanks so much you guys for giving me your thoughts today. Thank you for listening to ARCast.
Izak: Thank you.
Eliaz: Bye bye.

[music]
Ron: Hey, I hope you enjoyed that one. Eliaz and Izak, that was really terrific. I had such a great time in Israel. I met so many people who listen to ARCast and just a terrific event at their developer academy. I've just had a great time.

Just got back from Slovenia, which is a beautiful, beautiful country. In fact, it reminds me a lot of right here in Washington.

Let's see, coming up in just a couple of weeks, I'll be heading off to the US Tech Ed. I'm looking forward to meeting a lot of you and so if you come by the technical learning center where the architecture area is, I'll be hanging out there, be recording some ARCasts and so stop by and say "Hi." Who knows you might end up on ARCast TV.

So we'll see you next time on ARCast TV.