Here is my understanding of how enterprises specify, deliver and manage process-centric applications:
The main roles include:
Business analyst or consultants interact with business users to gather the requirements of the business process. They often use tools like Microsoft Word, Visio Diagrams and mock-ups of HTML screens to capture those requirements. They are not expected to be technical or understand programming constructs.
A corporate developer is then responsible for mapping the specification into design and implementation and tying the logical flow with the actual applications, portals and services. A new level of detail and variability is introduced here: data transformation, exception management, timeouts, business transactions, etc...
Finally business users need activity monitoring and business reporting.
The main tasks involved include: Specification (owned by business analyst)
Implementation (owned by corporate developer)
Delivery and administration (owned by ops)
Activity monitoring (for business users)
Customization and adaptbility (rapid cycle business user, business analyst, corporate developer)
I would appreciate feedback to this picture.
I really don't have any issues with the methodology you are stating above. However, the following activities should be considered when approaching application integration (which is not to say that these are the only steps in an application integration project). Our strategy relies on a practical approach to application integration. We reuse some of the activities we've learned with traditional database design, application design, and development. Many times, we use the same design patterns to bind applications together as we did to build them. After all, there is no need to reinvent the wheel if the result will only confuse an already complex process.
This pragmatic approach relies on familiar concepts and terms such as metadata, schemas, object-oriented modeling, object-oriented analysis and design (OOA/OOD), patterns, and "good old" requirements-gathering techniques. Our suggestion for integrating applications relies on a simple set of techniques, our own "12-step program":
1. Understanding the enterprise and problem domain
2. Making sense of the data
3. Making sense of the processes
4. Identifying any application interfaces
5. Identifying the business events
6. Identifying the data transformation scenarios
7. Mapping information movement
8. Applying technology
9. Testing, testing, testing
10. Considering performance
11. Defining the value
12. Creating maintenance procedures
Dig Deeper on Topics Archive
Related Q&A from David Linthicum
David Linthicum explains what advanced business application programming (ABAP)/4 means. Continue Reading
David Linthicum defines Service Component Architecture (SCA) and Service Data Objects (SDO) and explains how to best build these components to enable... Continue Reading
David Linthicum explains how it is possible that Apache Tomcat is both a Web server and an application server. Continue Reading