As discussed previously, principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development. Principles are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.
Principles consist of the principle statement, rationale, and implications. Though the wording for principles should remain consistent, the rational and implications will evolve over time, as an organization responds to factors such as the current IT environment, internal initiatives, external forces and markets, and changes in mission, vision, and strategic plan.
In my prior role as an Enterprise Architect, I used the following Principles for the foundation of the Enterprise Applications. Even with the changes in the industry since I last wrote these - public, private and hybrid cloud computing, dev-ops, etc - these principles have been steadfast.
As an organization matures in its journey towards IT-as-a-Service, it becomes increasingly apparent that this is unachievable without increased workload virtualization.
An organization must adapt its IT Governance and adopt a "virtualization first" policy for application workloads. Only then will they be on the path tp realize the full potential of the software-defined datacenter.
This governance process is one in which through which all workloads (net-new, or refreshed) will be deployed as or on virtual machines unless exempted through an virtualization candidate criteria or through an exception process with appropriate override authorization. Any workload, is subject to the governance process - for example, Mission Critical, Business Critical, Business Important or Supporting Function workloads.
To be clear, this is not an article about technology. Rather, it is about the organizational, cultural and strategic factors that must be considered to improve the management of data, or information, within organisations.
There are two types of data: structured data and unstructured data. Structured data refers to data that is kept and managed through database management systems. Unstructured data refers to data refers to information that either does not have a pre-defined data model and/or does not fit well into relational tables. Unstructured information is typically text-heavy, but may contain data such as dates, numbers, and facts as well.
Effective information management is not simple, but this article draws together a number of ‘critical success factors’ for management of structured data for business transaction processing at or on behalf of an organization. These do not provide an exhaustive list, but do offer a series of principles that can be used to guide the planning and implementation of data management activities. While there is some overlap with business intelligence best practices, these principles do not universally apply to data kept for analytical processing in data warehouses.
The goals of an Enterprise Architecture Program standards process should be:
Technical excellence,
Adoption of proven technology in the environment,
Clear, concise, and easily understood documentation,
Openness and fairness,
Timeliness and
Organization-wide distribution and use.
To that end, organizations should create procedures that are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Enterprise Architecture standards. At each stage of the standardization process, a specification should repeatedly discussed and its merits debated in open meetings and via community discussion in an Enterprise Architecture Program Community.
There are two, primary development processes and documentation sources for Enterprise Architecture Program standards that I recommend.
Domain Teams and Ad-Hoc Working Groups
Requests for Comments (RFC).
Let's take a look at the concept of Domain Teams and Ad-Hoc Working Groups.
Enterprise Architecture domain teams are convened by the Enterprise Architecture Office to develop standards and guidelines for information systems. The work of the domain teams is consensus-based. The domain teams produce reports that include recommended principles, architecture patterns and bricks, and recommendations for action.
The Enterprise Architecture domain teams are temporary teams established to develop Enterprise Architecture artifacts within a specific domain of the Enterprise Architecture. For example, a domain team may be assembled to validate a data model, which is a specific model of the Information Architecture. Or, a domain team may be assembled to develop an architecture brick that lists approved standards for a specific technology such as enterprise level database management systems, web-servers or operating systems.
Another method for documenting Enterprise Architecture standards and best community practices is the Request for Comments (RFC) series. Any stakeholder or working group can propose a new standard or best community practice using this document series.
The process by which domain teams and working groups develop Enterprise Architecture artifacts is one based on consensus. As illustrated in the sections below, domain expert teams and working groups follow a structured process for reaching consensus.
This process ensures cross-organizatio representation, consensus, and alignment.
Most of the time a stakeholder request (individual or governing body) leads to the identification of a need to establish or update a standard. However, there are other ways a need is identified. For example, the Enterprise Architecture Office may initiate an internal project that requires the organization-wide perspective that domain teams provide. Or, it is possible that the Requests for Comments (RFC) process is not able to produce a standard, in which case the Enterprise Architecture Office may decide to establish a domain team.
After the need is identified, the Enterprise Architects may determine that a domain team is the most appropriate standards development process to meet the need.
Exit Criteria:
The Enterprise Architects determines a domain team should be established.
Stakeholders or Enterprise Architects determine a working group should be established.
Once the Enterprise Architecture Office determines that a domain team will be convened, they will define the scope of the domain team. Then, a formal request is sent to technology business unit directors and/or manager and other relevant stakeholders (as determined by the Enterprise Architecture Office) to nominate members for the domain team. The Enterprise Architecture Office then selects the team members.
Because all technology business units are invited to participate in the domain team process, it is assumed the business units have delegated decision-making authority to their respective representatives. Therefore, it is assumed that the domain teams’ recommendations have been vetted by the business units.
A working group can also be convened to develop a standard or best practice. Working groups are comprised of stakeholders who may include individuals, groups, and organizations. Contributions from working groups may be unsolicited.
The domain team or working group begins its work with a formal orientation, or training, kickoff session, during which all members are informed of the work to be accomplished by the team and the plan to accomplish it. The domain team or working group then begins its work. The following are the basic steps each domain team or working group performs to develop their recommendations:
Understand the current state for the team’s technology area of focus. (For teams that are selecting technology standards this will be defining the current baseline for the specific technology area [i.e., technical domain]).
Establish or validate guiding principles.
Finalize the decision criteria the team will use to make its decisions.
As appropriate, conduct market research to ensure a complete scan of all available products and technologies within the technical domain, and understand the strengths and weaknesses of each vis-à-vis the decision criteria.
As appropriate, write and issue a Request for Information (RFI) so that all vendors have an opportunity to be included in the evaluation process.
Deliberate to achieve consensus based on analysis of available information (i.e., current baseline, market research).
Develop recommendations.
Compile the team’s next steps and final recommendations.
After the domain team or working group completes its analysis and finalizes its recommendations, it documents its recommendations in the form of a summary presentation, which the team will present to the Enterprise Architecture Governance Committee or other governing bodies as needed.
During this step the appropriate decision making authority(ies) review the working group's recommendations and either approve or reject the working group's proposed standard; or request further analysis. The RFC author then incorporates recommendations, if any, into the final RFC.
During this step the appropriate decision making authority(ies) review the domain team’s recommendations and either approve or reject the domain team’s recommendation; or request further analysis.
The IT Management Committee Enterprise Architecture Subcommittee reviews the domain team reports, develops comments and recommendations on the disposition of the domain teams’ findings, and forwards the reports with their recommendations and findings to the Enterprise Architecture Governance Committee. The Enterprise Architecture Governance Committee is the approval authority for the architecture recommendations contained in the reports. The IT Governance Committee is the final authority on disputed recommendations from the domain teams’ findings and recommendations.
The Enterprise Architecture Program publishes the approved changes online to the Enterprise Architecture Program Library and notifies all Enterprise Architecture Program stakeholders.
Update to the Enterprise Architecture Program website with the results and artifacts of the domain team (e.g., principles, bricks and patterns, et al.)
The following groups are used throughout this the Enterprise Architecture concepts I present on this site. More full descriptions may be provided in an example Enterprise Architecture Charter.