Trinity's approach to any client work is to:

• Leverage existing assets. Existing assets include client documents, work from previous consulting firms, industry best practices, and Trinity's repository of reusable assets.
• Build a team. Trinity's approach is not to assume that in this complex IT world of today that one person knows everything and can perform every task. Trinity also understands that the Trinity team is a subset of a much larger team. Trinity's work must be done in context of the client's business and other business relationships.
• Accountability. Trinity's team is lead by a technical project manager that understands all the tasks to be completed for the project and is responsible to ensure the Trinity resources with the right skill sets and experience is available when needed by the project. The client always has one point of contact for questions and concerns.
• Estimating Review & Support Costs. Unfortunately with most IT projects it is not known at the time of project inception the number of use cases, test cases, and other artifacts that will be produced by the project. For this reason, the approach to estimating review or support tasks is to:
  • Estimate effort known for key deliverables (e.g. Requirements, RFP, Architecture document, Test Plan)
  • Estimate the effort required for on-going management and communication tasks (e.g. status reports, issue management).
  • Estimate the effort to perform other review tasks as a “level of effort” based on the duration of the project. The results of this work will be provided on a weekly basis to the client. A senior Trinity staff will access all the deliverables and recommend to the client the deliverables that should get the most emphasis. This is typically based on the key risks for the project (e.g. new technology, lack of clear requirements).

Technical Delivery & Validation Approach

The following diagram provides an overview of the approach and context in which key technical deliverables are developed or validated:

Click image to enlarge.

The Trinity methodology is based on the following key principles:

1. Leverage Industry Standard Methodologies. Trinity combines the leading industry standard methodologies to provide a comprehensive, yet non-proprietary methodology. The diagram illustrates that in different subject matters, different industry standards are leveraged. For example, IT Infrastructure Library (ITIL) is leveraged for service management, Rational Unified Process (RUP) is leveraged for architecture definition, and IEEE is leveraged for requirements and configuration management best practices.
2. Leverage More Than Experience, Leverage Existing Assets. Trinity not only brings experienced staff to the engagement, but has an extensive repository of Principles, Policies, Practices, Architecture Models, Requirements, Checklists, etc. to leverage so the work can concentrate on the client's needs.
3. Acknowledge the Enterprise Context. Whether all these architectures are part of the engagement scope, it is important to realize that the project exists within the context of the larger enterprise:
   • Business Architecture. The business architecture is the collection of business processes, use cases, requirements, and business rules. The technical work should be business-driven. For a Service-Oriented Architecture (SOA), the goal is to have the business processes drive the identification of services.
   • Enterprise Architecture. The enterprise architecture is the collection of IT principles, policies, practices, and processes that facilitate the enterprise-level goals (e.g. integration, reuse).
   • System Architecture. The system architecture is the collection of architecture views that define the target system sufficiently to drive the system development life cycle. The system architecture should align with the enterprise architecture.
4. Define/Refine Supporting Processes. Supporting processes are critical to the delivery of any IT solution. Trinity recognizes that these processes are important to facilitate quality, cost containment, and communications. In an SOA environment, more emphasis is placed on Service Level Agreements (SLAs) and service support.
5. Build a Common Infrastructure. SOA is good for integrating disparate systems, but the goal to reduce the development of “connectors”, training costs, and maintenance costs is to have a common application infrastructure. In an SOA environment, some examples include an SOA Governance Framework, LDAP Repository, and Service Registry/Repository.

See our Standards & Resources section to see the industry standards that we apply in our projects.