You all know what TCO is and if you don't, quickly go and read about. Because I have a surprise for you.

Yesterday, I met with the TCO. It was a one hour meeting, but I did manage to characterize for myself.

It is a man, in my case he was European. He has a degree in over-engineering from a well known establishment.

From what he told me, he had many years of experience in high-end applications, mainly in the maintenance of infrastructure.

He spoke gently about the importance of responsibility, accountability and management.

When I explained my wishes, he talked about good process, control, security and procedure.

He did not know much about WEB 2.0, SaaS, Agile and other fancy words in the software world.

In other words, he is a plumber of bytes, and we all need a plumber.

By the way, he earns more than all the memory and disk you could think of for your application.

Now, how to reduce the TCO?

Hope you sleep well at night.

Yours truly,

Noam

I hope that by now you read the stream of posts about increasing the number of users.
Previous posts: 1, 2, 3

Now, I will show an idea that you may use. I do not protect this idea but it would be nice to know if you tried to implement it.

Some borring information in text:

Keep fighting for your voice to be heard,

With you all the way,

Noam

So, did you wait long? I hope the anticipation was not too hard.

Following my last post I would like to fulfill my promise.

Last time I stopped the flow of writing with the idea of looking for somebody in the organization that is not the application user.

Also, try to find what in the application, would interest this somebody or even better, assist them to do their work.

I will jump directly to a real life example.

Imagine yourself as a truck driver. You work in an independent logistics firm and sometimes you deliver goods for some company's warehouse.
Let's call it SCW. Now, imagine a hot day and you arrive with your truck to SCW. At the gate, the gatekeeper checks your papers and tells you that this delivery is totally unexpected and you cannot unload or even get in because of new security regulations.

Now what? You could park your truck, try to walk into SCW and raise hell until they found out what went wrong.
Another alternative for the less aggressive would be to call your office and they will try to get hold of the purchasing guy or the SCW manager and sort it out.
Both alternative will take a lot of time and the day is hot.

Now back to your reality as a developer. What would the truck driver need out of your application? It is simple, the person that can help and solve the problem.
How would he get it? simple, he got a paper with a Delivery number, this paper was issued from the application. Someone created it, probably it has a reference to a Purchase order or Sales order. There must be some contacts there.

If you, the developer, could expose this information to the driver via extranet, that would be great and by doing one phone call the problem is solved.

Now the only task is, how to expose this data. I think you already know how. After all, you developed the application.

One last request from my side: You are welcome to add your comments and ideas in the comments section.

See you next time,

Noam

Hello to all developers out there.

Back to the question of increasing the number of users of your system.

Following my previous post http://itgumbo.com/openforbusiness/2008/09/how_to_increase_the_numbers_of.php.

Lets start with a protest:
This is a BLOG for developers. You may think that this kind of ideas should be raised by your friendly Product Definition colleague.
Now would you?
No! I say, developers should take responsibility into their own hands. Ideas for new functionality can come up by simply looking at your users.

So, back to reality. What is required is to get familiar with non-users in the customer's organization.

For example, you probably know the accounting department because they call you all the time.

Now the question is, who are they serving? who serves them? within that periphery you should find at least one who is not a user of your system.

This guy (or girl) is not your user but he interacts with users, so maybe there is some need there.

Maybe these poor fellows who need the service of the accounting department (poor them) need some information in that area but it is not accessible to them.

So, my dear developer, you should know your customers, go and find out these guys and characterize them.

Once you do it, the next idea will pop.

I promise that in the next posts, I will share one idea of mine that you will be able to use.

Power to the developer!

Noam

Most enterprise applications, ERP, CRM and others are charged by the number of users.

So, the main challenge of these software vendors is how to increase the number of users.

Even in the cases that the customer is charged by usage, the purpose is to increase the number of transactions that users are doing.

There are traditionally two ways:

1. Add more functionality that will appeal to more users
2. Wait until the customer organization will grow and increase the number of users.

I would guess that the latter is realistic but requires too much endurance.

So, what is the functionality to add? again there are two alternatives:

1. Add to the application modules that will cover new areas of business
2. Offer new services on top of the existing data and functionality

Personally, I would prefer the latter. This alternative is requires less effort and more creative thinking.

I have one idea that I will share in another posts. But in the meanwhile, I would start with the following direction:

How many employees in an organizations are also users of ERP, CRM etc? I would guess that no more than 50% in any given organization for any given application.

It could be that most employees are using some application, but you, my dear, are concerned only with one application. Your own!!.

So the direction is to find who are the employees that are not using your application and what would they need out of it. Simple daa!!!

See you in the next post,

Noam

I was in a philosophical mood this week and I wondered why do we still read the books on paper?

Wasn't there a promise, 10-20 years ago, that in a very short time we will not need any paper?

It really took me sometime and effort to realize why - It is not comfortable.

I am not saying that the devices are not comfortable, some would think they are. I do not argue with that.

I am saying, we do not feel comfortable enough to read a book without paper. Again, some would argue about it.

So I have my killer argument:

How many of you who feel comfortable to read a book from your comfortable laptop, would take the laptop to the toilet?

I got you there.

Please take it as a metaphor for any time you hear about some technology that grab hold on our existing habits.

Your truly,

Noam

Today I would like to discuss the modeling trend.

You all heard about modeling that will replace coding. Or maybe you didn't?

So, quick explanation. Modeling creates metadata. The metadata is interpreted by some framework or engine. The framework or engine run something according to the metadata thus, according to the modeling.

Nice, no coding for the one who model, very sophisticated coding for the one who writes the engine.

But is it true, is this really the next step in world of software development?

First, what does it mean to model?

You start with a modeling environment, hopefully, a graphic one. You start to draw some model. After the easy graphic phase of drawing some shapes and name them, you start with the details.

The details are never easy. You think about the relationship between the shapes you just draw, you think about the process that these shapes are part of.

Congratulations, you are programming!!!

It is not code, it is partially graphical, but it is coding in a new language.

So, what would you prefer?

Coding or Modeling?

Please leave your answer in the comments below.

Thanks,

Noam

Just before farewell: UI design is a different discussion.

Powered by Qumana

So, after the lengthy discussion about the need for multiple technologies, is there a good reason for it?

Beside the simple fact that this enables you to handle the same business content with multiple technologies I could see 2 more benefits:

1. When the business logic application is a legacy system, it could be not service friendly.
   You could still manage the business content of the service in the same development tool of the legacy application and let modern tools with interoperability to the legacy application to handle the service ennoblement.

2. Normally, business logic is more sustainable than technology. I think you would agree that the Purchase order content that you know, haven't changed much during all your career. Technologies do change. We are not yet finished implementing with SOAP and suddenly there comes JSON.
   If you decouple service technology from business content, you will have less work when service technology will change.

Just for nostalgia and also to prove a point, I got this Purchase order from 1937. Anyone can now compare it the Purchase order they know.

http://legacy.library.ucsf.edu/action/document/page?tid=fbn31a00

I got it from:http://legacy.library.ucsf.edu/ . This is a good site if you are interested in business archeology.

Have a good week and service well.

Yours truly,

Noam

I would like to elaborate the discussion about service enabling.

It is tempting and also less work expose the service in a specific technology e.g. HTTP/SOAP.

As seen in my another post:

This should work.

The question now is: Is this satisfactory? Do you really can plan of having only a single technology?

The answer as you could expected, is NO.

In real life we are working in more than one service consumption technology. Just take the good old Purchase order. We want to query it with HTTP/SOAP for our Portal, we want to download it to a file, we want send it by mail and this just contemporary technologies that we are working with now.

The sad truth is that we accumulate legacy technologies over time and we cannot dispose them. For example: EDI, SQL views, FTP.
Should I mention more?

So, the conclusion is: for the same business content we need more than one exposure technology. That brings me to the following:

The layer of Service logic is focused only on producing and processing the service business content, the message.

The Service technology layer knows how to handle data object that could be processed by the Service logic layer.

• In case of inbound calls, the Service technology layer will handle the call and create the data object and pass it to an object in Service logic layer to process it.

• In case of outbound calls, an object in the Service logic layer will prepare the data object and will pass it to Service technology object that will handle the sending.

Have a good week and service well.

Yours truly,

Noam

In the last post I discussed the service content and logic. I will return to that in future posts in greater details.

Now it is time to get more practical. Let’s have one roundtrip of development around the service block.

I will try to explain my view on the best practice of service enablement architecture.

I already discussed the difference between the application's Business logic and the Service logic. This logic separation already suggests the architecture but there is also a twist in the plot.

It should be clear by now that the Service logic is coded based on the Business logic without changing it. This would mean a layer on top of the Business logic.

First, you need to identify your Business logic layer. Naturally you would look on your application and say: there it is!

Let’s make life easy and assume that the Business logic you need resides in that single application. If there are more applications involved, you are in the cloudy zone of words like mash-ups and composites.

Back to that single application, how do you connect to the Business logic?

A bit of pessimism: it may be, that the Business logic layer is not so clear. This is typical in legacy systems and other systems that are simply not designed for API. I am sorry that I cannot give any solution here. Every case is different and every solution is innovative by itself.

The only idea I can contribute is the following diagram:

If you are lucky, you are on the tip of the arrow. If not, look for the less friendly Classes, function or database tables.

And now, to the architecture. To complete the task of service enablement.

Please note the important details:

1. The Business objects in the Business logic layer may not really exist. If you want to be ready for the future, it would be a nice idea to wrap your Assets of Business logic as objects.

2. The Service providers layer is a separate component for coding and deployment. In case of a legacy system with older technology, consider to code the Service layer in a modern technology that can interoperate with the older technology.
   Trying to use older technology for SOAP services could be frustrating but challenging.

In my next post I will show the twist in the plot that I mentioned.

Wish you all a great job and interesting projects.

Noam

Powered by Qumana

I would like to follow-up my previous post and elaborate on the service design and implementation.

Let's take the "Create Sales order" service. After the decision about what data would be used in the service message, there is the time to find how to process it.

When you create a simple Sales order you have the header with dates, addresses, totals and customer data. On the order lines you would have the products, prices and quantity.

Let's focus on the header. How would the customer be represented in the message?

Basically, there are 2 alternatives:

1. With the required customer data such as Name, address, phone etc. This is comprehensive approach but costly.
2. With a customer key. This is good only if you have created the Customer first and also shared the data with the service consumer.

Actually in a generic design, both alternatives should be used.

So what next? Now it is the time to design the service provider.

First you need to allocate the underlying business objects. That could vary from database tables and up to a set of classes that manage the business object.

In our example it would be at least: Sales order, Customer and Product.

Why don't we just expose each business object and let the consumer decide what to do?

The answer is simple, there is some logic that we know about in the underlying business objects. This logic originate from the associations between those and required validation and other functionality. For example, we do not want to confuse our service consumer with questions like: Is the order total comply to the Customers profile? We normally do not want to expose the fact that we have a Customer profile.

We want to keep the control of that logic and make the consumer work easier.

So, I would like to suggest the term: Service logic. This is the logic that is specific for the service functionality while based on the underlying business logic.

In my previous post I mentioned the resembles to UI design. So, if there is UI logic, there should be Service logic.

In my next post I will elaborate on the technical implementation that is derived from this.

I have a small request, I would like to discuss these ideas. If you feel that this is new, old, trivial, fantastic or any other opinion, I would like to read it in the comment.

Thanks for your interest,

Noam

Today I would like to discuss a very basic issues that could sound trivial.

When we decide to expose something as a service, what exactly do we expose?

Normally, you have some application or engine that has the functionality you want to expose.

For example, you want to expose the ability to create a Sales order over the web. So, design a message for the service.

Now is the time to think, do you expose the Sales order as it appears in the server or maybe in the UI?

Usually these alternatives are far from each other.

• The server side Sales order has a normalized data structure including the separation of Product and Customer to different objects.

• The UI Sales order is aimed for the user comfort and not keeping any strict data design rules.

Sometimes it seems that requirements are clear because they came directly from the service consumer. This is very tempting but you have to think about reusability of the service. What another consumer would need a similar service but with slightly different Response?

So, back again, what will you expose?

I would like to suggest the following approach:

1. Think as a UI designer. The UI designer thinks about the end users and the way they would work with the  system. You are the "UI" designer for your fellow developers that will consume the service.

   • Think about usability How easy it would be to understand what the service is actually doing.

   • Are the data types you use in the Request and Response clear? Use known terms, not internal terms.

   • Do you provide enough content in the Response?

2. Think about the use case you are solving. There are different ways to expose a service for "Create Sales order"

   • For B2B, you will probably add more information to the data type such as Product name and description.

   • For A2A, you could assume some common master data repository, so the Product could be represented only by its key.

3. Try to guess the future requirement from that service. Making the service more genric will increase its reusability and reduce any future changes.

4.  And finally, review your service with colleagues that are not developers, preferably, product managers. They will be able to rate the usability from the business point of view.

In my next post, I will talk more about the implementation regarding service exposure.

Best wishes,

Noam

I am a software architect with 12 years experience in applications development.

I worked in companies from large enterprises such as Motorola and SAP down to start-up's that you will never hear about.

My motivation for this blog is to share my experience and ideas about application development, integration and process management.

I hope that you will benefit from this blog.

See you in the next post,

Noam