Richard Veryard

In "Pragmatic data analysis" (1984) Veryard presented data analysis as a branch of systems analysis, which shared the same principles. His position on data modelling would appear to be implicit in the term data analysis.[4] He presented two philosophical attitudes towards data modeling, which he called "semantic relativism and semantic absolutism. According to the absolutist way of thinking, there is only one correct or ideal way of modeling anything: each object in the real world must be represented by a particular construct. Semantic relativism, on the other hand, believe that most things in the real world can be modeled in many different ways, using basic constructs".[5][6]

Veryard further examined the problem of the discovery of classes and objects. This may proceed from a number of different models, that capture the requirements of the problem domain. Abbott (1983) proposed that each search starts from a textual description of the problem. Ward (1989) and Seidewitz and Stark (1986) suggested starting from the products of structured analysis, namely data flow diagrams. Veryard examined the same problem from the perspective of data modeling.[7]

Veryard made the point, that the modeler has some choice in whether to use an entity, relationship or attribute to represent a given universe of discourse (UoD) concept.[8] This justifies a common position, that "data models of the same UoD may differ, but the differences are the result of shortcomings in the data modeling language. The argument is that data modeling is essentially descriptive, but that current data modeling languages allow some choice in how the description is documented."[8]

In the 1991 book "The Economics of Information Systems and Software", edited by Veryard, experts from various areas, including business administration, project management, software engineering and economics, contribute their expertise concerning the economics of systems software, including evaluation of benefits, types of information and project costs and management.[9]

In the 1993 book "Information Coordination: The Management of Information Models, Systems, and Organizations" Veryard gives a snapshot of the state of the art around these subjects. "Maximizing the value of corporate data depends upon being able to manage information models both within and between businesses. A centralized information model is not appropriate for many organizations," Veryard explains.[10]

His book "takes the approach that multiple information models exist and the differences and links between them have to be managed. Coordination is currently an area of both intensive theoretical speculation and of practical research and development. Information Coordination explains practical guidelines for information management, both from on-going research and from recent field experience with CASE tools and methods".[10][11]

In the 1990s Veryard worked together in an Enterprise Computing Project and developed a version of Business Relationship Modelling specifically for Open Distributed Processing, under the name Enterprise Modelling Methodology/Open Distributed Processing (EMM/ODP).[12][13] EMM/ODP proposed some new techniques and method extensions for enterprise modelling for distributed systems.

In 2001 Veryard introduced the concept of "component-based business". Component-based business relates to new business architectures, in which "an enterprise is configured as a dynamic network of components providing business services to one another".[14] In the new millennium there has been "a phenomenal growth in this kind of new autonomous business services, fuelled largely by the internet and e-business".[14]

The concept of "component-Based Business constitutes a radical challenge to traditional notions of strategy, planning, requirements, quality and change, and tries to help you improve how you think through the practical difficulties and opportunities of the component-based business". This applied to both hardware and software, and to business relationships.[14]

Veryard's subsequent work on organic planning for SOA has been referenced by a number of authors.[15]

In "Six Viewpoints of Business Architecture" Veryard describes business architecture as "a practice (or collection of practices) associated with business performance, strategy and structure."[16]

And furthermore about the main task of the business architect:

The business architect is expected to take responsibility for some set of stakeholder concerns, in collaboration with a number of related business and architectural roles, including

• business strategy planning, business change management, business analysis, etc.

• business operations, business excellence, etc.

• enterprise architecture, solution architecture, data/process architecture, systems architecture, etc.

Conventional accounts of business architecture are often framed within a particular agenda - especially an IT-driven agenda. Many enterprise architecture frameworks follow this agenda, and this affects how they describe business architecture and its relationship with other architectures (such as IT systems architecture). Indeed, business architecture is often seen as little more than a precursor to system architecture - an attempt to derive systems requirements.[16]