Requirements Management and Architecture

1. Software Requirements Specification (SRS). The Software Requirements Specification is a high-level technical paper consumable by non-technical people. It is typically created by a business analyst or analysts and reviewed by a team of piers. After a satisfactory review, the SRS is passed to a Program Manager and Development Team.
2. Software Architecture Document (SAD). This is a well-known template from the arsenal of the Rational Unified Process. The Software Architecture Document is created by the development team under the direction of the Program Manager while consulting the Software Requirements Specification.

Links for 2008-06-25

Interesting Enterprise Architecture links gathered from all over the Internet

Overheidsservicebus: OSB - Ontwikkelingen binnen de elektronische overheid zitten in een stroomversnelling. De dienstverlening naar burgers en bedrijven neemt sterk toe. Hierdoor groeit de noodzaak van samenwerking tussen overheidsinstellingen en vindt er steeds meer informatie-uit more...
(tags: architecture)

Enterprise Architecture Resources

A number of relevant organizations and resources are provided below.

The Open Group Architecture Framework (TOGAF)

The Open Group Architecture Forum

Download / purchase TOGAF 8.1.1

View TOGAF 8.1.1 online

EA Tool Evaluation Criteria (TOGAF 8.1.1)

Mapping the TOGAF ADM to the Zachman Framework (TOGAF 8.1.1)

The Zachman Framework

The Zachman Framework (PDF Download)

The Zachman Institute for Framework Advancement

Archimate

Archimate starters kit and Visio Stencils

SOA Governance

The purpose of Service Oriented Architecture (SOA) governance is to ensure that the investments in SOA deployments made by the organization deliver the anticipated benefits both in the short term and throughout their entire lifetime. SOA is intended to be a long-term architecture, so it is reasonable to expect that some of the resources being deployed now will be in use for decades.

SOA governance therefore entails design-time procedures and best practices that deliver services with the best business fit, and with due consideration to the reuse of services by subsequent projects.

Key issues:

• SOA cannot be planned and implemented by IT on its own, but must be a collaborative effort between business and IT.
• Technology-driven SOA projects are unlikely to enjoy the degree of reuse that SOA should enable, due to the lack of emphasis on designing services around business fit.
• Although supporting technologies will be needed, it is more important to put in place the organizational structure and to ensure the right people are put in the right roles.
• The resources dedicated to SOA governance need to be kept proportionate to the extent of the SOA deployment, the rate of change experienced, and the degree of risk to which it is exposed.

Links for 2008-06-20

Interesting Enterprise Architecture links gathered from all over the Internet

Web Services Architecture
(tags: architecture webservices SOA soap standards w3c internet)