A Service-Oriented Enterprise

The following is an idea I pitched to the head of our IS department. It's an SOA-like architecture, with some implementation details thrown in.
Unfortunately, he wasn't impressed.

A Transaction Queue-Based System
· All requests for processing have a strict definition and structure.
· All requests are sent to a request processing service on a central server and saved to a queue on disk.
· A completely different service on the same or different server deserializes these requests in order of priority or time of request, performs the task, and reports back to the user.
· All duplicate requests are logged, and the initial request is always given priority.

Priority for tasks is determined statically by Quality as well as dynamically based on previous TTC (Time To Completion). TTC priority is used mostly for short tasks like "Submit ATT Reading" or "Mark Piece".

Framework:
Functionality is based around a singular, remotable, serializable object representing a request to perform a task.

Base Request object contains:
· Requestor - Network Name, IP, User, etc.
· Request - Definition, Time of submission, TTC (delta)
· Destination - Automatically determined destination service for horizontal scalability.

Base Interface contains:
· Above Signature
· Manual Success Check (Fail-Safe)
· Security Context – Credentials required to access secure sources. This does NOT consist of passwords and the like, rather a security “context” which describes why the information is requested. Actual credentials are handled by the lower layers.

All layers of the system have access to Business Objects for easy translation of messages and objects.

Services:
Service Broker:
· Liaison between a floor application and SQL Server or other back-end.
· Accepts requests and places them in the Queue.
· Reports back to user when completed.
Request Processing Service:
· Sifts through request queue, processing requests by priority.
· Reports back to user when completed.
Request Reporter:
· Reports back to user when completed.
· This may reside in the Secretary or Processing service. The location of said functionality depends on how the completed requests are stored.

Anytime Request Viewer:
· A Windows Event Viewer-type application that allows viewing of pending requests, and after a logon, manual manipulation of priority and On-Demand execution.

Associated Applications:
Service Manager:
· Validates users and provides simple application management capabilities.
· Manages Enterprise/Machine/User-level settings.
Front-End apps:
· All front-end apps will only have access to the Request Secretary, to maintain security.

Scalability:
Vertical:
· Multiple client access is a native capability.
Horizontal:
· Each Service maintains metrics about its load, and can split up processing tasks among its instances.
· Instances are referred to by name, just as in SQL Server.

Fail-Safe Facilities:
· All Requests have a FS/MCS (Fail-Safe/Manual Success Check) in case the reporting service is not available. This contains the steps necessary to validate that the task was completed successfully.
· Tasks will be defined by the Request Library and will not be editable by developers.
· Tasks that take more than 30 seconds are reported on early, tasks taking more than 2 minutes are reported on periodically.
· Failed requests are logged, and reported to the user. Successive failures are reported to a higher authority.

I have a majority of the code completed, but since my boss refuses to read C# for fear of embarrassment over the fact that he has no clue what a delegate is, until I have something substantial, he's clueless.
As soon as I have a working prototype, I'll post some code.

Letter to my employer

To Whom It May Concern:

This company’s so-called “system” is in an irreparable state.
The how and when of this atrocity’s collapse needs to be
addressed.
Replacement of our current system with foreign methodologies
will only become a determent to the process and speed its inevitable demise.

I place no specific blame on those whose ignorance may have
caused this lack of design, and no amount of meetings and complaining amongst
the IS department will be anything but counter-productive towards the goal of
replacing this system.

In order to save this company, one of two things must occur:

1)Ignore the problems. Let the existing system remain and work with it as long as
possible and wait for all things to grind to a halt. Then move on to step 2.

2) Shut down the plant for a given period, and design a new system from scratch.
Decide on a single, standardized, and strictly enforced
set of processes and methodologies, construct a new system around it, and
“re-boot” the plant with this new system.

Neither of these options sounds in any way conceivable to
anyone with a business-oriented mind, but I honesty think that the former will
occur if nothing is done.

I realize that hearing something like this from someone in
my position may even be considered “crossing the line,” but you must believe
that I only have the best interest of the company in mind.

I could provide you with several examples to prove the above
claims, and even if you were to refuse all possibility of such a dramatic
change, I still want you to be aware of what I believe to be the inevitable.

I want this company to succeed just as much as anyone, and I
believe that in order for that to happen, I must express my fears and concerns
now. If you would like to meet in private about these concerns, I would be more
than happy to elaborate on what I have stated here.

Sincerely,
nibbles&bits