6 years, 10 months ago

Example of a high level Ontology supporting Architect roles.

Link: http://theknowledgeeconomy.anorien.com/2014/06/11/example-of-a-high-level-ontology-supporting-architect-roles/

It has been unfortunate that the term Enterprise Architect has been in many cases regarded as being more closely aligned to IT rather than the ‘whole of business’ as was originally intended.

Supporting the ontology offered for discussion are the following high-level descriptions of the included architect roles. The inclusion of the word ‘Holistic’ along with the Enterprise Architect is there to provide an indication of the extensive scope that is expected to be encompassed by this role.

This example ontology has included the role of the Enterprise IT Architect who works closely with a Business Architect. It is highly likely the a business which has significant architecture capability will have the these two roles rather than the first.

The last of the roles described is the Product Architect. This role which can be typed in two distinct ways, has been included in response to the analysis of the survey of advertised Australian architecture roles, some of which could be aligned to Product Architect.

Holistic/Enterprise ArchitectThe Enterprise Architect works closely with stakeholders, management and subject matter experts, using their awareness of market and legislative influences to build a holistic view of the business’s strategy, processes, information, and information technology assets. The Enterprise Architect applies this knowledge and ensures, through advice and governance, that the business and IT are in alignment. Linking the business mission, strategy, and processes of the business to its Information, Communications and Technology strategy, and capturing this using multiple architectural models or views that show how the current and future needs of the business will be met in an efficient, sustainable, and timely manner.
Business ArchitectThe Business Architect plays a key role in structuring the enterprise in terms of its governance structure, business processes, and business information. Aligning strategic goals and objectives with decisions regarding products and services; partners and suppliers; business; capabilities; and key business and IT initiatives. The primary foci of the Business Architect are the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the enterprise using a repeatable approach, cohesive framework, and available industry standard techniques.
Enterprise IT ArchitectAn Enterprise IT architect (EITA) takes the business strategy and working with the Business Architect (where one exists) defines an IT systems architecture to support that strategy. EITAs must understand the business and be able to dive deeply into technology issues to ensure business goals and objectives are serviced efficiently.
Business Domain ArchitectThe Business Domain Architect provides solutions to satisfy business requirements within very specific boundaries. Using similar skills to the Business Architect they are focused on narrower business outcomes. Business domains may cover diverse areas such as Healthcare, Mining, Card Payments, Insurance, Payroll and CRM etc.
Technology Domain ArchitectThe Technology Domain Architect provides solutions to satisfy the technology requirements needed to support the business within very specific boundaries. Using similar skills to the Enterprise IT Architect they are focused on narrower technology outcomes. Technology domains will include Application Architecture, Information and Data Architectures, Integration and Technology Services Architecture and Infrastructure Architectures. Depending on the business Technology Domain Architects may also include, amongst many others, Virtualisation, Geospatial, Business Intelligence and Analytics.
Portfolio ArchitectA Portfolio Architect’s primary focus is on the solutions supporting collections of projects or programs and other work that are grouped together to facilitate effective delivery of capabilities needed to satisfy strategic business objectives. The projects or programs of the portfolio may not necessarily be interdependent or directly related.
Programme ArchitectA Programme Architect’s primary focus is on the solutions supporting groups of functionally related projects required to deliver an integrated system or capability. Programmes may include elements of related work outside of the scope of the discrete projects in the programme to ensure seamless integration and delivery of maximum business benefit.
Solution ArchitectSolution Architects provide technical leadership within a project. They articulate both the technology and product positioning and the requisite alignment to the Enterprise Architecture to both business and technical users. A Solution Architect will evaluate current client environments, identify solution risks and issues and recommend ‘best practice’ solutions that can deliver the outcome that best supports their customer’s business requirements.
Product ArchitectThe Product Architect can take two distinct types within a business setting. The first is the Product Architect who has specific product (eg Citrix) knowledge. They may operate within a specific Business or IT domain and develop solutions as does a Solution Architect but incorporating the products for which they have expertise. The second type of Product Architect takes responsibility for providing solutions using the products and services that business offers its customers. The Product Architect will also identify and recommend solutions based on additional non existing products and services or enhancements that support the business goals and objectives.

The above table is, like the ontology, included for discussion purposes. The definitions of the roles are neither definitive nor complete.

A complete ontology would include, well as high-level role descriptions, an indication of the skills they would require to fulfill the requirements of any given role.

It should be noted that any given individual architect is likely to have many skills not needed to fulfill a specific role. It is expected that that architect is likely over their career, to fill many different architecture roles exercising the requisite skills as they are needed.

Unfortunately the many-skilled architect, employed to fill one role, may be expected to wear multiple hats, using their extended skill set but attracting remuneration for the lesser role.

Hopefully these descriptions along with the ontology provide a seed that initiates appropriate action as to what is actually needed to support the Architecture function within business.