Five Aspects of Service Design

There are five aspects of design that need to be considered:

1. The design of the services, including all of the functional requirements, resources and capabilities needed and agreed
2. The design of service management systems and tools, especially the Service Portfolio, for the management and control of services through their lifecycle
3. The design of the technology architectures and management systems required to provide the services
4. The design of the processes needed to design, transition, operate and improve the services, the architectures and the processes themselves 
5. The design of the measurement methods and metrics of the services, the architectures and their constituent components and the processes.

Business Value

With good Service Design it will be possible to deliver quality, cost-effective services and to ensure that the
business requirements are being met. The following benefits are as a result of good Service Design practice:

1. Reduced total cost of ownership (TCO): cost of ownership can only be minimized if all aspects of services, processes and technology are designed properly and implemented against the design
2. Improved quality of service: both service and operational quality will be enhanced
3. Improved consistency of service: as services are designed within the corporate strategy, architectures and constraints
4. Easier implementation of new or changed services: as there is integrated and full Service Design, and the production of comprehensives Service Design Packages
5. Improved service alignment: involvement from the conception of the service ensuring that new or changed services match business needs, with services designed to meet Service Level Requirements
6. More effective service performance: with incorporation and recognition of Capacity, Financial, Availability and IT Service Continuity plans
7. Improved IT governance: assists with the implementation and communication of a set of controls for effective governance of IT
8. More effective service management and IT processes: processes will be designed with optimal quality and cost-effectiveness
9. Improved information and decision-making: more comprehensive and effective measurements and metrics will enable better decision-making and continual improvement of service management practices in the design stage of the Service Lifecycle.

Messaging Chennels

Point-to-Point Channel

Publish-Subscribe Channel

Datatype Channel

Message Bus

An enterprise contains several existing systems that must be able to share data and operate in a unified manner in response to a set of common business requests.

Scenario One (problem)

Solution

Scenario Two (solution)

Messaging Systems

Messaging makes applications loosely coupled by communicating asynchronously, which also makes the communication more reliable because the two applications do not have to be running at the same time. Messaging makes the messaging system responsible for transferring data from one application to another, so the applications can focus on what data they need to share but not worry so much about how to share it.

Channels — Messaging applications transmit data through a Message Channel, a virtual pipe that connects a sender to a receiver. A newly installed messaging system doesn’t contain any channels; you must determine how your applications need to communicate and then create the channels to facilitate it.

Messages — A Message is an atomic packet of data that can be transmitted on a channel. Thus to transmit data, an application must break the data into one or more packets, wrap each packet as a message, and then send the message on a channel. Likewise, a receiver application receives a message and must extract the data from the message to process it. The message system will try repeatedly to deliver the message (e.g., transmit it from the sender to the receiver) until it succeeds.

Multi-step delivery (or pipes & filters)— In the simplest case, the message system delivers a message directly from the sender’s computer to the receiver’s computer. However, actions often need to be performed on the message after it is sent by its original sender but before it is received by its final receiver. For example, the message may have to be validated or transformed because the receiver expects a different message format than the sender. A Pipes and Filters architecture describes how multiple processing steps can be chained together using channels.

Routing — In a large enterprise with numerous applications and channels to connect them, a message may have to go through several channels to reach its final destination. The route a message must follow may be so complex that the original sender does not know what channel will get the message to the final receiver. Instead, the original sender sends the message to a Message Router, an application component and filter in the pipes-and-filters architecture, which will determine how to navigate the channel topology and direct the message to the final receiver, or at least to the next router.

Transformation — Various applications may not agree on the format for the same conceptual data; the sender formats the message one way, yet the receiver expects it to be formatted another way. To reconcile this, the message must go through an intermediate filter, a Message Translator, that converts the message from one format to another.

Endpoints — An application does not have some built-in capability to interface with a messaging system. Rather, it must contain a layer of code that knows both how the application works and how the messaging system works, bridging the two so that they work together. This bridge code is a set of coordinated Message Endpoints that enable the application to send and receive messages.

Message Endpoint

The application and the messaging system are two separate sets of software. The application provides functionally for some type of user, whereas the messaging system manages messaging channels for transmitting messages for communication. Even if the messaging system is incorporated as a fundamental part of the application, it is still a separate, specialized provider of functionality much like a database management system or a web server. Because the application and the messaging system are separate, they must have a way to connect and work together.

Connect an application to a messaging channel using a Message Endpoint, a client of the messaging system that the application can then use to send or receive messages.

Message Translator

Use a special filter, a Message Translator, between other filters or applications to translate one data format into another.

Chaining Transformations

Message Router

Multiple processing steps in a Pipes and Filters chain are connected by Message Channels. A Message Channel decouples the sender and the receiver of a Message. This means that multiple applications can publish Messages to a Message Channel. As a result, a message channel can contain messages from different sources that may have to be treated differently based on the type of the message or other criteria. You could create a separate Message Channel for each message type (a concept explained in more detail later as a Datatype Channel) and connect each channel to the required processing steps for that message type. However, this would require the message
originators to be aware of the selection criteria for different processing steps, so that they can publish the message to the correct channel. It could also lead to an explosion of the number of Message Channels. Also, the decision on which steps the message undergoes may not just depend on the origin of the message. For example, we could imagine a situation where the destination of
a message changes by the number of messages that have passed through the channel so far. No single originator would know this number and would therefore be unable to send the message to the correct channel.

Insert a special filter, a Message Router, which consumes a Message from one Message Channel and republishes it to a different Message Channel channel depending on a set of conditions.

Parallel Processing

However, the overall system throughput is limited by the slowest process in the chain. To improve throughput we can deploy multiple parallel instances of that process to improve throughput. In this scenario, a Point-to-Point Channel with Competing Consumers is needed to guarantee that each message on the channel is consumed by exactly one of N available processors. This allows us to speed up the most time-intensive process and improve overall throughput. However, this configuration can cause messages to be processed out of order. If the sequence of messages is critical, we can only run one instance of each component or use a Resequencer.

Pipeline Processing

Connecting components with asynchronous Message Channels allows each unit in the chain to operate in its own thread or its own process. When a unit has completed processing one message it can send the message to the output channel and immediately start processing another message.

Pipes & Filters

Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).

Message

Package the information into a Message, a data record that the messaging system can transmit
through a message channel.

A message consists of two basic parts:

1. Header – Information used by the messaging system that describes the data being transmitted, its origin, its destination, and so on.
2. 2. Body – The data being transmitted; generally ignored by the messaging system and simply transmitted as-is.

Message Channel

Once a group of applications have a messaging system available, it's tempting to think that any application can communicate with any other application any time desired.

Integration Styles - Application Integration Options

File Transfer — Have each application produce files of shared data for others to consume, and consume files that others have produced.

Shared Database — Have the applications store the data they wish to share in a common database.

Remote Procedure Invocation — Have each application expose some of its procedures so that they can be invoked remotely, and have applications invoke those to run behavior and exchange data.

Messaging — Have each application connect to a common messaging system, and exchange data and invoke behavior using messages.

Decision Criteria

Application coupling — Even integrated applications should minimize their dependencies on each other so that each can evolve without causing problems for the others. Tightly coupled applications make numerous assumptions about how the other applications work; when the applications change and break those assumptions, the integration breaks. The interface for integrating applications should be specific enough to implement useful functionality, but general enough to allow that implementation to change as needed.

Integration simplicity — When integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed. Yet changes and new code will usually be necessary to provide good integration functionality, and the approaches with the least impact on the application may not provide the best integration into the enterprise.

Integration technology — Different integration techniques require varying amounts of specialized software and hardware. These special tools can be expensive, can lead to vendor lock-in, and increase the burden on developers to understand how to use the tools to integrate applications.

Data format — Integrated applications must agree on the format of the data they exchange, or must have an intermediate traslator to unify applications that insist on different data formats. A related issue is data format evolution and extensibility—how the format can change over time and how that will affect the applications.

Data timeliness — Integration should minimize the length of time between when one application decides to share some data and other applications have that data. Data should be exchanged frequently in small chunks, rather than waiting to exchange a large set of unrelated items. Applications should be informed as soon as shared data is ready for consumption. Latency in data sharing has to be factored into the integration design; the longer sharing can take, the more opportunity for shared data to become stale, and the more complex integration becomes.

Data or functionality — Integrated applications may not want to simply share data, they may wish to share functionality such that each application can invoke the functionality in the others. Invoking functionality remotely can be difficult to achieve, and even though it may seem the same as invoking local functionality, it works quite differently, with significant consequences for how well the integration works.

Asynchronicity — Computer processing is typically synchronous, such that a procedure waits while its subprocedure executes. It’s a given that the subprocedure is available when the procedure wants to invoke it. However, a procedure may not want to wait for the subprocedure to execute; it may want to invoke the subprocedure asynchronously, starting the subprocedure but then letting it execute in the background. This is especially true of integrated applications, where the remote application may not be running or the network may be unavailable—the source application may wish to simply make shared data available or log a request for a subprocedure call, but then go on to other work confident that the remote application will act
sometime later.

Basic Elements of an Integration Solution

Thinking Asynchronously

Messaging is an asynchronous technology, which enables delivery to be retried until it succeeds. In contrast, most applications use synchronous function calls; for example: a procedure calling a sub-procedure, one method calling another method, or one procedure invoking another remotely through a remote procedure call (RPC) (such as CORBA and DCOM). Synchronous calls imply that the calling process is halted while the sub-process is executing a function. Even in an RPC scenario, where the called sub-procedure executes in a different process, the caller blocks until the sub-procedure returns control (and the results) to the caller. When using asynchronous messaging, the caller uses a send and forget approach that allows it to continue to execute after it sends the message. As a result, the calling procedure continues to run while the sub-procedure is being invoked.

Message Transmission Step-by-step

Integration Problems

Interesting applications rarely live in isolation. Whether your sales application must interface with your inventory application, your procurement application must connect to an auction site, or your PDA’s PIM must synchronize with the corporate calendar server, it seems like any application can be made better by integrating it with other applications.

All integration solutions have to deal with a few fundamental challenges:

• Networks are unreliable. Integration solutions have to transport data from one computer to another across networks. Compared to a process running on a single computer, distributed computing has to be prepared to deal with a much larger set of possible problems. Often times, two systems to be integrated are separated by continents and data between them has to travel through phone-lines, LAN segments, routers, switches, public networks, and satellite links. Each of these steps can cause delays or interruptions.
• Networks are slow. Sending data across a network is multiple orders of magnitude slower than making a local method call. Designing a widely distributed solution the same way you would approach a single application could have disastrous performance implications.
• Any two applications are different. Integration solutions need to transmit information between systems that use different programming languages, operating platforms, and data formats. An integration solution needs to be able to interface with all these different technologies.
• Change is inevitable. Applications change over time. An integration solution has to keep pace with changes in the applications it connects. Integration solutions can easily get caught in an avalanche effect of changes – if one system changes, all other systems may be affected. An integration solution needs to minimize the dependencies from one system to another by using loose coupling between applications.

IT Architects

Software Philosophy

• Correct - Correctness is the key aspect of any software system. If a system doesn't do what it's supposed to, then what's the point?
• Simple - I adhere to the "Keep It Simple Stupid" (KISS) principle. Simple generally means small, so I strive to write small classes (generally under 100 lines) and small methods (generally under five lines). Doing so allows my classes and methods to adhere to the Single Responsibility Principle. I like to submit early and often, so that each submission is simple and easy for reviewers to understand. I believe in not writing code until it's actually needed, also known as the You Ain't Gonna Need It (YAGNI) principle. I agree with Donald Knuth's take on premature optimization - it is the root of all evil! I also love Tony Hoare's quote on simplicity - "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
• Well-named - Naming is so important in software. A little extra time spent upfront deciding on a good name pays dividends in the short-term and years down the road.
• Free from duplication - I adhere to the Don't Repeat Yourself (DRY) principle. Relentlessly seek duplication in your software and work to remove it.
• Automatically tested - Write automated unit tests as you write your production classes. Treat the automated tests as a first-class user of the production classes, let them reveal code smells, and address those smells! Write automated functional tests early and build up a suite that takes the drudgery out of manual testing.
• Consistent - Each team should have a set of conventions and use an automated tool (such as Sonar) to ensure the conventions are adhered to. It's more important to remain consistent than to fight over the actual conventions used.
• Documented - Every public package, class, and method should be documented. Every parameter and possible return value should be explained. Note that I agree with Robert Martin in that comments are a failure. As a developer, I strive to express myself in code so that I don't have to rely on comments to communicate my intent.
• Reviewed - Software should be reviewed early and often and code authours should be open to any feedback from reviews.  Modern online code review tools (such asAtlassian Crucible) allow for painless reviews.