Re: Application design & architecture

Rob,

I am off to teach color to a blind person.
Trevor

Subject: Re: Application design & architecture

Trevor

Trevor Perry wrote:

Rob,

Go read this article:
http://www.infoworld.com/article/06/05/02/77996_HNsoalink_1.html?source=rss&url=http://www.infoworld.com/article/06/05/02/77996_HNsoalink_1.html

Quote: "SOA's not hype. SOA and Web services are moving beyond the 'connect things together' stage. We're at a point where it's becoming a part of the

mainstream," Schmelzer said.
"That's a bit less sexy, because you're getting down to brass tacks:
implementation details, not the big news stories," Schmelzer said.

This told me very little.

Ok, you have asked a LOT of questions. I will take the bait. I would

suspect, though, that you would be better off doing your own research rather

than argue with mine.

I want answers to questions - not to have an argument.  In any event you
are trying to persuade me, and presumably others on this list, that SOA
has merit.  I didn't ask you to do so, but if you had come up with good
answers to my questions below, I might have done some research into SOA.
Unfortunately nothing that you wrote has encourage me to do this - in
fact quite the reverse.

Doesn't it pull together existing tools, languages etc. If so, even if
it provides a solid foundation for them, those programs, modules - call
them what you will - will be the lowest common denominator and be the
weak points of the SOA solution.

Certainly your existing applications, if they are using outdated approaches,

will be weak points. There has to be some form of modernization to allow

your existing code and applications to be re-used. For example, you may have

some business rules inside an RPG program. These rules are effective in
running your business, and now you wish to extend their use beyond their

current scope. For example, a customer of yours may wish to know the status of their order. Use your existing order inquiry code, repackage it as a web service, expose it to the web securely, and allow your customers to consume

that web service inside their application. If your current order inquiry

code is not modular, then making it modular would be the first step. After

that, your weak points now become strong points.

So we have established that SOA is no magic button and if your existing
applications are not up to their task, SOA will not make them any
better.  The first task then is to improve your existing applications.
The second is to ensure that we build better ones in the future and I
don't see how SOA will help.

How long is the learning curve before someone could start to develop a
useable robust scaleable SOA solution?

Yes. How long is a piece of string? How long did it take you to learn _____?

The answer is that it depends on your approach. Most System i shops that
have had success with SOA 'solutions' have started with XML.

Why XML?  I have yet to learn what this has to do with anything useful
other than transferring data between systems and you later refer to
this.  My question relates to the real world and any sensible manager
considering a new tool/method etc. would ask it.  You haven't answered.

 They find a
business reason to consume a web service

What does this mean?  What is a web service? Just an application that
works over the Web?

and integrate that into their

current application suite. This has the added advantage of allowing them to learn more about SOA from the bottom up, by understanding the concept of a

web service - that is, what is a business process, and how is it defined.
One small step, and you are on your way.

What is the approximate percentage improvement in development
productivity compared with traditional methods TAKING THE WHOLE
DEVELOPMENT CYCLE?

This is not a starter question. And again, there are too many variables.
What skill set do you have in your IT shop? What business applications do

you have? Are you already modular/ILE? Are you able to introduce change? Do

you have strategic thinking business management?

.
I am sorry Trevor but that is not an answer.

In what way does SOA help to simplify the processes of development?

Many ways. Here are five:

1) Modularization. Maintenance of modules has proven to be much cheaper than

maintenance of legacy linear programs.

I have been writing object-oriented modular code for over 20 years.
What does SOA add?

2) Re-use. IBM preaches governance, and consider this key to SOA. If you
know your environment, then you will know when a module can be re-used.

But if your system had some intelligence, it would know and the
developer wouldn't need to care

Instead of traditional subroutine repetition, business processes will be
built and linked together when needed.
3) New applications. As your business processes are already built, new
application development will comprise more choreography and orchestration
than new coding.

4) Leveraging partner development. When you have a business process that is

required in an application, and it has been developed by someone else -
let's say a customer credit check - your application can consume the

partners service. You have less coding, and therefore less maintenance. If you want to argue about the quality of a partner's code, why would you be in

business with them if you did not trust that?

If proper standards were enforced by the development technology, then
all applications would automatically be integrated.  I can show you this
working

5) Loosely coupled. When your business needs change, and you partner with
someone else, switching your web service to consume a credit check from a
different business partner does not require re-coding. SOA includes open
standards like web services for this purpose.

To what extent does SOA automtically enable reuse of
methods/objects/code etc?

It does not. Your Architecture dictates how re-use will happen.

But I thought that SOA was architecture?  Anyway, it should do this
automatically

Certainly,
governance will assist in the ability to re-use processes. Moving into an
SOA world will require better standards than we traditionally have.

But few people adhere to standards properly and mostly they never will,
whatever management tells them.  Therefore we need to find a way of
enforcing standards subliminally.  That is what I decided to do.

Does SOA allow incremental development without the need for a most
detailed specification before development begins?

Building applications should always require a business specification. To

what extent you detail that specification is up to your SOA. In the end, if you are writing code, it seems obvious that a program specification should

be written.

Does SOA help us to write LESS code?  Why do we write code?  Do we need
to write so much code?

The difference is that the SOA has defined the interfaces, the
structure, the foundation, etc..

Does SOA require physical file design?

SOA is not technology. It is not software or hardware.

Then what is it?  Smoke and mirrors?

Once you are building
the application to conform to the Architecture, you will be designing

physical files. If your Architecture dictates normalization, then you will

design accordingly.

I do know what normalisation is about, but it should not be necessary
for system developers to understand a totally artifical process that
bears little relationship to the real world.  Is your brain normalised?
Mine certainly isn't, particularly after I have had a few beers!

How does the performance of SOA applications compare with other methods?

SOA is Architecture. The concept of performance is going to be defined by
your environment. Sure, the Architecture will leverage your existing
infrastructure, and it will certainly be aware of performance, but SOA
'applications' will perform as well as they are written.

There certainly are performance issues to be concerned about. For example, XML is used as a common transport mechanism. XML is text-based, and if you

were to send large amounts of data, you could easily impact performance
negatively. If this were to be the case, your SOA might offer alternative
transport mechanisms as the standard between applications.

But shouldn't you build your applications so that they share the same
data, without redundancy?  Then the transport wouldn't be necessary

In what way does SOA help to simplify the processes of maintenance?

Modularity. Leveraging partner applications.

I.e. it doesn't

Does SOA allow you to change file layouts without shutting down
applications?

SOA is not technology. It does not require a language or hardware or
software - that will be dependent upon the business and their

infrastructure. If your development tools require this, then I would assume

they will continue to require this - SOA or not.

So SOA adds nothing, yet how much more easily could we react to user
change requests if we could change file layouts without shutting down
systems.  I implemented this over twenty years ago.  I am amazed the
that lastest technology cannot do it.

How does SOA help to provide 24/7 solutions with automatic parallel
duplicate databases for rapid recovery after a major disaster?

It doesn't. This is infrastructure, not architecture of business
applications. DR or HA would be part of your business strategy, and
certainly the SOA would recognize that.

So SOA adds nothing

How does SOA overcome the inability of relational databases to model the
muti-dimensional complexity of the real world?

SOA does not overcome the inability of the developer to do anything. SOA is architecture. With a valid Service-Oriented Architecture, business are truly

interoperable in a way we could not fathom when relational databases were

introduced. The inability of relational databases to model anything should

not be a factor in building an SOA.

So yet again, SOA is unable to solve a very serious problem.  In my
view, RDBMSs are holding back the progress of the IT industry and its
users.  The concept is now 37 years old and we should have progressed
since then

Does SOA require greater or less technical skills than existing methods?

SOA requires additional skills,

I assumed that.  What is required is an architecture that requires less
skills so that we can be more productive.

because most developers do not have an
understanding of the tools needed to consume or expose web services. Most

System i developers do not have an understanding of modules, but with their

existing skills, they could easily learn these next steps. SOA does not
require the programmer to be any better, it requires that they understand
where their code fits into the big picture.

What hands-on experience do you have of actually using SOA?

Smart-ass questions do not help explain SOA.

This most certainly was not a smart-ass question.  I might say that a
Rolls-Royce is the best car in the world and list all its features, but
if I have never driven one or any of its direct competitors, how would I
know?

Thanks for your attention. Next challenge?

Are you meaning to imply that you succeeded in that one?


I am not sure why but I am reminded of childhood poetry by Robert Louis
Stevenson

I HAVE a little shadow that goes in and out with me,
And what can be the use of him is more than I can see.


You have successfully convinced me that SOA is vapour ware and has no
real use.  Its acronym is too similar to SAA and I always thought that
that was a waste of time and time has proved me right.

What we need is less complexity - not more.

It seems to me that SOAs main purpose will be to allow consultants to
rachet up enormous bills, but will do very little for developers or users.

Rob