Pragmatic Software Design

16 Candidate Reusable Capabilities for Business Processes

2009-11-16T02:00:08Z

Here area set of ideas, candidate assets if you will, of reusable software capabilities for your business processes. Please don't take these as capabilities you have to build from scratch. Instead, view them as part of your overall BPM software infrastructure. Most of these capabilities could be provided by a single vendor or using an abstraction layer, you can realize these using multiple ones. You can also prioritize this list when evaluating vendor offerings.

Rule driven Exception Handler: Integrate exception handling with business rules engine. The rules could determine how to resolve, mitigate, and handle errors. It will also specify routing instructions for errors requiring human intervention.

Internationalization Support: Status messages driven by a resource bundle as opposed to a single locale. Additional locale-specific resource bundles can be added as required for your business needs.

Seamless Cross Channel Movement: Enable a business process to start in one sales channel and get completed in another. Idea is to support business processes that start, pause, and get reactivated via an alternate channel. For example, a user can start ordering a book online and request a customer service rep to finish the process. The idea is to have the user's in-progress process instance data get placed in appropriate work queues in a new business process or in a new state on the original one .

Business Process Completion API: Ability to determine % complete for any business process based on the state of the process instance . This API can provide the ability to get current status, estimate completion time (e.g. based on historical data), and what steps are remaining for the process instance to finish.

Business Activity Hold & Retry API: Facilitate pause, resume, and delegation of any business activity based on business rules. This interface would put processing on hold as well for one or more process instances.

Authentication: Enabling integration with a LDAP store, or providing digital certificate based security for interfaces that instantiate the business process are examples here.

Entitlements API: Enable fine grained authorizations for business activities and business processes. Role based entitlements for events - i.e. if a particular user role cannot initiate a business process or execute a particular activity, the software infrastructure should prevent those actions.

Content Management integration: Integrate with content management system to serve targeted content based on state of business process or to augment data in a process instance.

Event Integration API: Capture or derive events and handle them using one or more business processes. This could also impact existing process instances that are in-flight.

Indexed Search Integration API: Ability to execute full-text search as well as categorized search using an indexed search engine against completed and in-progress business process instances. E.g. search all process instances from a particular division or with a particular customer code, or category etc.

Process Dashboarding: Provide key business process metrics - report real time status of availability, performance, usage statistics, escalations, etc. Also provide ability to override/adjust in-flight process instances based on business scenarios.

Business Process Preferences API: Manage a set of process-level preferences. E.g. default logging level for all tasks could be set to high or all notifications get delivered to additional recipients, or data fixes will get audited a different way etc.

Document Integration: Attach documents using information in a process instance and attach/route content as part of the business process orchestration.

SLA Adherence API: Manage service level agreement specifications associated with end to end business process as well as key business activities. Ability to define/handle, and proactively prevent SLA violations.

KPI Definition and Monitoring API: Monitor business processes to capture key process indicators based on business process. E.g. number of accounts opened today, number of accounts opened after multiple validation errors etc.

Building Contract-First Service Capabilities - Podcast Episode

2009-11-15T00:44:46Z

Posted an episode on building contract-first service capabilities at the reuse podcast series:

Download file

Service Capabilities Need to Address Supportablility

2009-11-08T20:14:42Z

Enterprise software systems have several needs one of which is supportability. It is critical that your system is supportable in the production environment. Teams that start thinking about supportability during the last stage of a development cycle or when transitioning support responsibilities to an external team discover many rude awakenings at the last minute. When designing SOA based solutions it is equally critical that supportability needs aren't ignored. Your service design needs to consider several aspects in this space:

1. How will your service handle exceptions? Does it throw it back to the calling application? If it is logging them, is the format and content agreed upon by your production support team?

2. Related to above, it is equally essential to accurately classify exceptions in the service (as much as possible that is). This will help handle and route via an automated fashion as well.

3. Is there a way you can ping your services without corrupting live data? Maybe you need to setup test data and periodically ensure the services are behaving normally. The other option, depending on your business need is to handle exceptions but return partial data or data that is a bit stale etc. The service capability can continue serving requests simultaneously reporting issues.

2. How will clients get answers to issues during runtime? Will they call your support team and if so, what information are they expected to provide? If you have a known list of issues, you can classify them as infrastructure, data, and business logic and provide relevant answers, additional links, and contacts.

4. If your support team cannot isolate an issue, how will they escalate? When they do, is there information that can be of value? For example, the client application or business process name and version, stack trace, time of error, error message may be essential for troubleshooting.

5. Ensure your services capture relevant metrics throughout the request processing cycle. When was the request received, when processing completed, and origin IP or queue name are essential for troubleshooting. Additional, service-specific metrics might need to be captured as well (e.g. your consumer might want to know the status of a request with a particular customer number or an account identifier).

6. Provide tools for your support team that will make it easy for them to monitor service health, reset resources (e.g. database connection pools), and toggle integration points (e.g. an external system that needs to process the output of your service logic). These tools are very useful and will save valuable time when production issues occur.

These are ideas that just scratch the surface. As service capabilities get reused across composite service orchestrations and business processes, supportability becomes extremely important. What have you done in your environment to make services more supportable?

10 Signs Your Team Needs Systematic Reuse

2009-11-01T22:08:07Z

In the hectic routines of projects and deadlines it is easy to ignore reuse. After all, we are delivering code, features, and churning out applications - aren't we? May be you are waiting for the right time to start and execute on a reuse strategy. May be you think software reuse is a big myth and isn't worth pursuing. Regardless of reason poor design will eventually inhibit your efforts to more more agile and responsive to business needs. Here are ten tell-tale signs that your team needs systematic reuse:

Management believes they can install or buy reuse. You are told reuse comes for "free" with OOPS, SOA, BPM, MDM, (you can add your favorite buzzwords here!). Nothing could be farther from the truth :-)
There is no management support for reuse. You typically hear some variation of deliver, execute, and just hit the deadline. What should be a small change rapidly mushrooms into something that touches several classes or services and forces you to change code across modules. To boot, this happens often. This of course adds technical debt and will hurt the team in the long term.
Developers love to build their custom implementations for which satisfactory solutions exist. It could exist in-house, in the open source community, or available commercially. We have all met the developer who wants to build a better logger than Log4J or a better dependency injection container than Spring. Whatever. The argument usually goes this way: we have special requirements that no one else has and we have the best talent to build it (maintenance, ongoing bugfixes, support costs are conveniently excluded).
No scope for reuse in the problem domain. Nothing can be considered for reuse you are told. Our domain is so unique that it changes often - nothing is common across projects or initiatives and we need to keep churning out code to meet business needs. This might be true to an extent but but not the way it is portrayed.
Your developers and technical leads tell you that their software assets are perfect - they have been made completely reusable for all future needs. Be very wary! Predicting the future is tricky and systematic reuse isn't going to guarantee perfection. More importantly, your investment in reuse is going to provide you the foundation to turn out new features and business processes quicker but doesn't eliminate the need for continuous evolution of those reusable capabilities.
There are several different versions of a common need like getting customer data or getting a database connection. Each with its own set of assumptions about data structure, error handling, etc. You know there is an opportunity to create a common capability but developers find it easy to cut and paste code from one project or component into another.
Each developer implements capabilities without the faintest idea of existing ones. You find duplication sprinkled liberally across your codebase - all trying to do the same thing in multiple ways. Each developer of course believes that they were the first ones to implement it (and implement it right!!).
Design is an after-thought you are told. Why waste time in design when you can implement? No, you don't want big design up front - and you also don't want the opposite. This sign usually manifests itself during testing - you discover the same need across sub-systems or modules. A little design would have discovered this as a reusable capability early on.
There is no investment in training, documentation, communication, or integration support for reusable assets. If you build it they won't come and you end up with a library of assets that are buggy, unusable, and worse - irrelevant to business needs.
You have no hooks in the development process that will help you proactively take advantage of reuse opportunities. Reuse if any happens ad-hoc due to heroic efforts of one or two developers sporadically.

Have any of these signs resonate with your experiences? are there additional ones you can suggest?

Build an Abstraction API for BPM Interaction

2009-10-27T23:36:14Z

Introduce an abstraction API when integrating with a BPM solution. Why do I say that? Several reasons:

Good software design practice to bind to an interface as opposed to an implementation. So individual applications won't be directly coupled with an external vendor solution.
Provides you the flexibility to augment solution using multiple vendors. Related to above point, you can utilize one vendor for a subset of capabilities and another for a different set.
This API can be the ideal place to integrate your enterprise capabilities within the context of BPM solutions. Instead of making one-off or tactical modifications to a vendor solution that could be both expensive and proprietary, you can augment missing capabilities using the abstraction API. For example, if the BPM solution doesn't support authentication based on active directory, this abstraction API can provide that capability (most likely you already have this component in your enterprise). Additionally, this is also the place to integrate horizontal capabilities such as message routing, metrics, monitoring, and error handling. Do you want your BPM solutions to report exceptions differently than other applications? In the same vein, this API can integrate with services or libraries that encrypt/hide sensitive data attributes before returning process state to a calling application. This has the potential to reduce duplication of such logic across user interfaces that integrate with related business processes.
Can potentially simplify complexities associated with a native API. If the native API needs a set of steps for starting process instances or get task/work items for a particular user - this abstraction API can simplify those calls. This not only makes it easier for integration but reduces the opportunities for errors across development efforts. This API in essence can act as a façade.
The API standardizes access to BPM capabilities and reduces the possibility of competing integration mechanisms across development efforts. If one team uses the native API as-is and another builds a new one on top - you have two ways of accessing the BPM engine. This problem gets worse as additional teams start to use BPM.
This API could also make every business process support a core set of functions in addition to start/stop/suspend/resume calls. For instance, every business process can provide a getCurrentStatus() or reassignProcessInstance() that will make it easier for managing processes at runtime.

This API could be realized as a web service depending on the level of heterogeneity and performance requirements. This would essentially act as a service enabler for your business processes.

The above list isn't exhaustive - are there additional ones to add to this list?

Understand Business Goals Before Implementing BPM Solutions

2009-10-26T00:01:01Z

Have you ever been part of a project where the technology choices, design decisions, and even low-level implementation details are determined prior to understanding the project's business goals? BPM engines are like other technologies - they are a tool in your toolkit to solve business problems through IT. It is critical that there is a good understanding of business goals and priorities before implementing solutions. For instance, do you know what is the single most important business driver behind the project? Is it to attract new customers? eliminate/reduce data entry? reduce cycle time across the entire value chain? If your stakeholders cannot agree on this, your BPM project will have a tough time.

BPM projects can help identify and potentially implement service capabilities that can be part of your service inventory. However, do you know the capabilities that are high priority for your business stakeholders? IT can easily implement services that are either tactical in scope or worse irrelevant to business priorities.

Naturally this topic has significant design implications. If you are integrating multiple applications as part of a BPM solution, how will you handle failed transactions/exceptions? Will alerts/notifications need to get generated from the proces flow? if yes, which steps have bottom line impact to the firm and how can mitigation be put in place? how will your existing legacy systems be exposed - will they directly get invoked from the process flow or go through a mediation layer? Is the business process facing internal or external customers? will your in-house staff need to pick-up and complete partially completed process instances? Now all these questions are extremely relevant - but without understanding the business goals you won't be able to invest design effort.

Disadvantages of Building Services Code-First

2009-10-23T10:36:07Z

Posted an episode on the disadvantages of pursuing a code-first approach to building service capabilities at the reuse podcast series:

Download file

Episode Highlights:
Most development environments provide tools for generating WSDL contracts using annotations or platform-specific tools. Existing classes can be easily exposed as service endpoints. Method signatures become web service operations and method parameters become service parameters. This saves time and effort for the immediate term.

From a service-orientation standpoint however, this approach has significant disadvantages:

1. tools that enable contract generation out of the box often have the risk of introducing platform-specific attributes, service implementation semantics that inhibit interoperability and consequently the reuse potential.
2. The implementation contract could also have identifiers (database primary key field for instance) or implementation specific attributes (connection parameter to a proprietary system) that will needlessly couple consumers with a specific implementation.
3. This approach also challenges the provider's ability to honor SLA policy requirements such as authentication/encryption etc.
4. Service capabilities also run the risk of not reuse entity definitions - business data model entities that will effectively decouple the service contract with the implementation
5. Adding to above is the risk of exposing inconsistent error handling, error messaging, error reporting that will be apparent to your consumers. Not to mention it makes it harder for the provider to support several different overlapping implementations!

Building a Data Services Product Line

2009-10-19T00:58:05Z

The data services product line is a suite of data services that can include services across customer, account, product, pricing, and document data domains providing several capabilities for several internal applications.

The suite of services can act as the single point of entry into interacting with core enterprise data, significantly increase reuse of core data assets across business processes, decrease time to market for new applications and services, decrease development, maintenance, and support costs across the data service domains, and be scalable and extensible as business usage and needs varied over time

Customer data, account data, and document data service capabilities can be considered as individual products in the overall product line. This product line can support several sources of variation that are effectively managed across individual services. Listed below is a subset of these variations:

• Data Format
• Data Structure
• Data Source
• Event Trigger
• Data Visibility
• Error Handling
• Data Translations
• Physical Transports
• Workflow/Human approvals

This isn't a comprehensive list but to show how data services can be built as a family of related service capabilities.

Design Techniques When Refactoring Legacy Systems - II

2009-10-11T16:28:41Z

This is a continuation of the earlier post on design techniques when refactoring legacy systems. This post talks about backward compatibility and

Keep backward compatibility in mind

If there is one thing that is tricky about refactoring legacy assets it is backward compatibility. Although this isn't often talked about this is a very critical aspect. Creating abstractions, loosening tight couplings, and creating wrappers are all good practices but unless your change guarantees no harm you might be stepping over landmines. A lot of pain can be avoided if you take this into account. Backward compatibility is a simple goal but isn't always easy to achieve. Here are some things to think about:
• You will need to make sure that you don't leave legacy data sources in any invalid state after the refactoring changes
• In most cases you cannot save new data values into legacy database tables. Legacy data values could have hidden, implicit, or multiple meanings that are hard to fix in a single iteration or even few iterations. The best thing is to keep chipping away slowly and opportunistically.
• The changes you make to legacy components cannot break inbound or outbound data feeds, batch jobs, or terminal emulations. I have sat through some tense meetings when things break and there is financial or reputation risk involved. Add tight time windows to correct and reprocess batch jobs this is something you want to be absolutely sure about.
• Ideally you want no consumer to directly call a legacy module. You should consider yourself lucky if you happen to be in such an environment.

Minimize point to point interactions with external systems

If legacy modules are sending data to external systems - this could be via remote terminal emulations, messaging, batch jobs, or FTP - you can introduce an abstraction layer that will break this link. The abstraction layer might need to wrap these legacy assets before you can use them but this has several benefits.
Although these practices seem straightforward you should never refactor in isolation. You most likely won't have a set of automated regression tests for your legacy application. Before making changes to your legacy code you need to be sure that new defects are not being introduced. The straightforward way to do this is using test driven development. You should:

Create a unit test
Run and watch it fail
Make the change to the legacy asset
Re-run the test to watch it pass (if not make the change, run the test, you get the idea!)

Repeat these steps for all the identified refactorings. At this point ensure that your reusable asset is integrated from the legacy app, the source code control repository is up to date, and the relevant automated tests are included in your regression test suite. You might be tempted to declare victory but resist the thought. Now you need to map out how you want to package, deploy, expose, and support this asset. For example, in the java platform the asset could be packages as a JAR. If this is a service, it could be SOAP over HTTP web service or available over JMS for queue based integrations. The key thing is that you identify the mechanics and decide what your strategy is for consuming the reusable asset.

Building Reusable Service Capabilities - Podcast Episode

2009-10-03T12:03:00Z

Posted an episode on building reusable service capabilities as part of SOA initiatives at the reuse podcast series:

Download file

Design Techniques When Refactoring Legacy Systems

2009-09-27T23:55:51Z

Many SOA initiatives leverage legacy capabilities when building new services. It is important to ensure legacy services are examined before leveraging them as-is. Here are some design techniques that I use when reviewing and refactoring legacy assets.

Loosen the tight coupling among modules
Understand the problem domain and work backwards
Wrap legacy assets
Keep backward compatibility in mind
Remove point to point interactions with external systems

This post will elaborate on the first three and I will write a follow up post on the other two.

Loosen the tight coupling among modules

We've all worked with a legacy system where one module talks to another one which talks to another. In fact, a rat's nest of tight couplings might be the accepted way to address business requirements. Loosening the coupling between these legacy modules is the first step towards reusing any of the functionality. While you are doing this you will make the overall system simpler, easier to maintain, and pay down years (sometimes decades!) of technical debt. Refactoring these tight couplings will be very painful but it does get easier over time. Remember that you don't have to completely refactor all the tight couplings. If you what is needed for your immediate iteration that should be okay. The more you bite the more time and effort you need to invest in ensuring you didn't break the existing application. Also, you are touching a legacy component or process because you have an identified need that needs to be fulfilled.

To loosen the tightly bound legacy modules you could pursue several tactics:

* Identify and refactor logic that is tightly bound to user interface screens. The user interface is a good place to look for all kinds of logic being out of place.
* Identify business rules or policies that are embedded alongside data access or business logic code. You will want to refactor as much as you can to externalize them. Because every team is different you can place them in a class, a method, a database table, configuration file, or even a rules engine as appropriate (see James Taylor's post on getting started on decision management). It is more important to encapsulate than the exact means through which you implement. There is always the next iteration or release to change your mind if you were incorrect the first time.
* Pick batch jobs or scheduled file feeds that are associated with the legacy modules in question. Often you will find connectivity, file parsing/formatting, business logic all tightly bound in them. You will want to pick and choose what you want to go after but its an excellent place to start your refactorings

Depending on the complexity and nature of the couplings some of these might not be necessary for each legacy asset. By eliminating the tight coupling you will be positioned to reuse the asset for future projects. Slowly but surely, you will transform the legacy application and meet your release goals.

Understand the problem domain and work backwards

Your legacy systems often have domain relevant assets that have accumulated over time. It does help to sometimes look at the domain capability and work backwards to design and code changes. If a legacy asset isn't straightforward to refactor I find this technique very useful. Instead of mulling over what to change in the legacy codebase think about what it is that you really want. If you identify the domain relevant capability the problem becomes simpler to tackle and the changes needed start to appear naturally. For instance, your user story might be to offer a discount for a select set of users based on some business criteria. Maybe you have a legacy process that accesses customer data, transforms them, merges the data with other data loads, calculates discounts, and sends letters to your customers. It also has logic to load large files and records some metrics on them. Make a head-on refactoring of this process and you will have trouble where to start the changes (not to mention the fear of breaking working code!). Instead, step back and remind yourself what you really need. You just need the discount calculation logic and nothing else. Refactor just this logic and create a DiscountCalcualator reusable asset. The rest can stay as-is and you can always come back for more refactorings.

Wrap Functionality

Your enterprise probably has legacy software assets that are extremely valuable. It is also possible that you don't have the time or extensive knowledge to fully refactor a legacy asset and create a new one for use. In such cases you might need to make do with leaving the legacy asset where it is and still use it for your needs. If you start reusing them as-is though you will end up with lots of point to point connections between your code and the legacy asset. It will become tricky to change, upgrade, or get rid of the legacy asset. You could break consuming code and force changes every time you touch the legacy asset. Worse, you will expose your legacy error codes, naming conventions, behaviors across your codebase. Create a component that wraps the legacy asset which is between the legacy asset and the consuming code. If you don't have a wrapper that truly encapsulates the legacy functionality it will serve only as a pass-through layer adding no value. This wrapper component helps you reuse these legacy assets by enhancing the underlying functionality. To be effective, this wrapper needs to do several things:

* If you have a team coding conventions/standards make sure this wrapper follows them.
* You will want to reuse existing assets for cross cutting functionality such as logging, error handling, and security
* You will need to translate legacy error codes, error messages, and use standard error codes
* If you need internationalization of messages/labels this wrapper can perform necessary translations
* If the wrapper is a web service you will want to reuse data types and XML schema contracts to get alignment with your logical data model. If it is a library component it needs to reuse existing base classes as appropriate.

The wrapped asset now can be reused by multiple consumers and you have the flexibility to change the implementation. You get to save time and still not introduce tight coupling into your codebase. Ask your team to stop using legacy assets directly and always go through the wrapper. Make this a practice when you consume legacy assets.

5 Tips Before You Embark On SOA Projects

2009-09-21T00:13:12Z

You are itching to board the SOA bus. Hold on a bit though because it is easy to get lost in the hype and miss the real point i.e. generation of business value. So here are 5 tips before you start your SOA initiatives.

#1 Seek clarity on how project goals align with your business strategy
What is the SOA initiative specifically achieving for your business? is it trying to optimize an existing business process? release new offerings to generate additional revenue? build the foundation for new ones to be hosted? enable self-service for your customers? make it easy for your partners to exchange data with you? Depending on what your business goals are, the SOA strategy needs to be thought out accordingly. No use investing in prototyping business-to-business integrations if your goal is to eliminate manual step in a business process internal to the organziation.

#2 Aspire to marry existing IT goals with SOA
I am sure SOA isn't the only thing your IT shop is pursuing. If you are trying to reduce storage costs or hosting costs align that with SOA. Same is the case if your shop is trying to execute on software product lines via architecture convergence. Decommissioning legacy systems is another one that can be tied to SOA goals. If you take a holistic view of your technology objectives, you will be surprised how effective the conversations around service orientation becomes. Without a good grasp of this, you can go in circles trying to get buy-in from key stakeholders across IT.

#3 Communicate with multiple levels of the technology organization
SOA needs several stakeholders to succeed. Your upper management, business stakeholders, technical leads, and developers all need to be aware of SOA goals, how your project fits into the overall SOA strategy, and how is it going to impact them. You may be enforcing technology standards, introducing governance steps, and changing tools. It is important not to give rude surprises to people who's support you need!

#4 Take stock of existing solutions and investments
Chances are your development teams have already built services. Or your enterprise has existing unused licenses. May be there is a team that is close to completing a prototype with an open-source solution. There might be message brokers or web services that need retrofitting per your new standards. Or they may need minimal rework. You should get familiar with existing investments so you can learn what worked easily, what took effort, where the challenges are, and possibly identify risks for your project. You may pleasantly surprise yourself with free code samples, or even service capabilities that you can leverage.

#5 Prepare a prioritized list of strategic SOA deliverables
Build a list of deliverables your project is going to contribute towards SOA. You may plan to enhance existing capabilities so they are more scalable and available. May be you will build a new suite of services that are potentially reusable for future projects. Or you will reduce costs by replacing a legacy system partially or completely. Whatever it is, get the prioritized list!

I wouldn't get too much into contract design, governance policies, message exchange patterns, and message routing. They are all important but unless one has the big picture it isn't useful to move forward

Reducing Integration Risks

2009-09-13T19:30:58Z

Many SOA solutions consist of integrating applications, services, and backend processes to fulfill business requirements. You can design these solutions for the absolute best case and you are sure to get disappointed in production. A more prudent approach is, as always, to design for the real world consisting of interruptions, exceptions, and unscheduled outages. Here are some pointers when designing integration solutions:

Depending on how much reliability you need consider using reliable messaging
Introduce appropriate level of abstraction with each integration point. You many end up with a rat's nest of point to point integrations only to find out that the system you integrated with is about to be decomissioned.i.e. you need to wrap legacy capabilities.
Provide administrative capabilities to manage each integration point. Ideally, you should be able to enable/disable and/or throttle the number of messages going through etc. This is exactly what Michael Nygard advises when talking about circuit breakers in his book Release It.
Make sure you can smoke test integration points after scheduled and unscheduled downtime. You don't want to find out that a routine patch deployed on a sunday is causing an outage for your business users monday morning.
Provide the ability to vary logging/auditing at runtime. For instance, specific to an integration point you might want to provide verbose logging to troubleshoot an issue and revert back to the normal level after the problem goes away. You shouldn't redeploy or restart the app for these eventualities.
Build as much contextual information as possible while generating exceptions. Integration points can be painful to troubleshoot without appropriate error detail. Also, you should design a solution for assessing the impact on your system. Expect your business users to ask questions like - how many transactions were impacted? what about transactions that were in-flight? when the problem is resolved, can the transactions resume processing? is there a report of all transactions that need to get completed today (due to SLA, regulatory, or financial reasons) and are being impacted?

These aren't exhaustive but to provide the reader with the need to tackle and address integration risks early.

Enterprise Data Services - Podcast Episode

2009-09-07T23:26:51Z

Posted an episode on enterprise data services and how they help with systematic reuse and master data management (MDM) initiatives at the reuse podcast series:

Download file

Think About Support Needs Early

2009-09-06T16:42:35Z

Too many projects wait till the very end to think about supportability. Your system or solution will not magically become supportable overnight. It is critical that your design efforts meet support needs. Here are some questions that will influence your design:

How will production support get notified of exceptions/incidents? Do they need notification real-time or periodically? You might need a notification component. Depending on your requirements, the component might need to send alerts/messages to one or more parties. You might also need to support sending messages to different destinations (mobile phones, support consoles).
What information needs to be provided in the application-specific logs? Error location, error code, stack trace, possible causes, and resolution information needs to be captured. Additionally, application specific logs might also capture time of error, machine name, and runtime statistics such as heapsize/thread usage etc.
How will an exception get resolved? Are there errors that need human intervention? Is there a need to pause transactions and resume processing when exceptions are resolved? Returning contextual and actionable information is essential in these cases. Depending on the volume and error categories you might want to design a facility for viewing exceptions and resubmitting failed transactions.

Equally important is the need to include as much detail about errors as possible. Without adequate details on the error it is not possible for your support staff to act on an issue. These needs become even more critical when pursuing SOA and BPM initiatives. Your supportability needs to extend beyond a single application and your ability to track events and transactions across multiple applications become critical. As more systems get integrated, it becomes imperative that your support staff is educated about error detection, resolution, and escalation.