Architecture-Based IT Valuation

Marc Lankhorst, Dick Quartel, woensdag 31 maart 2010

Supporting portfolio management and investment decisions

This paper outlines our architecture-based approach to IT valuation and portfolio management. It sketches how different valuation criteria can be combined and linked to architecture models, and how a first part of this approach is implemented in an architecture modeling tool. In this manner, the value (costs & benefits) of different elements in the architecture can be computed and attributed to the various goals of the organization, thus supporting well-informed IT investment decisions.


After almost half a century of IT developments, many large organizations face an unfavorable ratio between old (existing) IT and new IT. Because old IT systems tend to be monolithic, unwieldy and inflexible, organizations experience maintenance as difficult and modernization to meet new business demands as improbable. Some organizations spend up to 90% of their IT budget in 2009 on maintaining the existing IT landscape, leaving only 10% for innovation. If this trend of increasing budget requirements for existing IT is not reversed, then in the nearby future no budget at all will be available for new IT. In the worst case, innovation is squeezed out completely and budgets to spend on existing IT may become insufficient to perform crucial maintenance tasks.

By focusing on the value of IT instead of considering costs only, organizations can decide which IT really contributes to their business goals and make a well balanced division into budgets for maintenance, exploration, realization and phasing out. Traditionally, IT has often been regarded only as a cost center in business case calculations. Its less tangible benefits have often been more or less neglected in portfolio management decisions. Furthermore, in the past information systems tended to be relatively stand-alone, supporting a single business silo. This made it easier to attribute its costs and benefits.

Nowadays, however, IT systems and services are more and more interwoven with the business and may support many different activities, generate independent revenue streams, attract new business, et cetera. To create a clear insight in these effects, we need a valuation approach that takes as a starting point the overall coherence of the organization, its products and services, business processes, applications, and infrastructure, i.e., from the enterprise architecture.

Enterprise architecture makes the connection between enterprise goals and the business functions, processes, people, IT systems and infrastructure required to reach these goals. It also considers the enterprise as an interrelated whole, instead of as a set of unrelated point solutions for problems. The valuation approach described in this paper uses enterprise architecture models to relate business goals to the IT artifacts, such as services, processes and applications that realize these goals. In this way, the KPIs associated with each goal can be related to the relevant attributes of the IT artifacts. This enables the development of automated and model-based techniques to analyze KPIs and business goals. Moreover, by performing such analyses as part of the architectural design process, different design alternatives can be assessed with regard to their contribution to business goals. The enterprise architecture foundation ensures that local optimization is avoided and enterprise-wide effects of changes are taken into account.

This paper describes the ingredients for an integrated IT valuation method that uses architectural models as its backbone. First, we explore the generic business requirements that comprise the high-level strategy of the organization with respect to its IT, such as its value center approach and operating model. These strategic choices determine the aspects that need to be taken into account when assessing the value of the IT portfolio. Next, we describe in more detail how business requirements can be modeled in conjunction with the enterprise architecture of the organization. This helps in realizing the requirements traceability that is needed to perform a well-founded portfolio assessment.

Figure 1. Overall structure of our method.

Business requirements and enterprise architecture are the main inputs for Bedell’s method, which computes the ‘value’ of IT systems. The method takes the importance of IT systems to the business and the effectiveness of their support and creates aggregate metrics across the entire IT landscape. Such metrics should preferably be as concrete as possible. We describe how to decide on such criteria and indicators for various aspects of the IT landscape that need to be evaluated. These include quality attributes such as the ‘-ilities’ well-known from software engineering, and risk analysis criteria. Finally, we give a first outline of a method in which the above-mentioned ingredients are integrated, the structure of which is shown in Figure 1.

Determining the IT strategy

In putting a value to IT systems, projects and investments, it is highly important to first have a clear insight in the strategic choices the organization has made with respect to its IT operations.

Venkatraman (1997) presents one approach to differentiation in IT goals: the value center orientation for IT. The main idea is that each center represents a different way of extracting value from IT resources. Note that the centers are interdependent. Venkatraman considers four different value centers (see Figure 2). ‘The cost center reflects an operational focus that minimizes risks with a predominant focus on operational excellence. Service center, while still minimizing risk, aims to create IT-enabled business capability to support current strategies. Investment center, on the other hand, has a longer-term focus and aims to create new IT-based business capabilities. Finally, profit center is designed to deliver IT services to the external marketplace to realize incremental revenue as well as gain valuable learning and experience to become a world-class IT organization’. (Venkatraman, 1998).

So on the one hand, there are the cost center and service center approaches, focusing on current business strategies. On the other hand, there are investment center and profit center that aim at maximizing opportunities from IT resources and shaping future business strategies.

Figure 2. The concept of a value center (Venkatraman,1997)

For each center, specific business goals and performance indicators can be defined. This approach with different IT strategies fits with the focus of the IT valuation method our applied research project is constructing. The business strategy and the matching value centers provide important input for the choice of valuation and assessment criteria for the IT portfolio.

Cost center

IT that is typically positioned in the cost center is not related to business goals. Examples are the operational infrastructure involving most data centers, telecommunications network and routine maintenance like installing and removing equipment, answering questions and administrative support. Specific performance metrics are used as decision criteria, which are not related to business metrics. Cost center works well when input and output can be clearly related, like doubling the budget results in a performance increase by factor 3. Relevant performance metrics are quantitative in nature, for example costs per unit of something, maintenance costs per unit, or costs per employee. Such measures need to be benchmarked against performance metrics of other organizations in order to be able to find opportunities for improvement.

Service center

The service center aims to create IT-enabled business capabilities that drive current business strategy. IT resources create tangible current business advantages. IT is strongly related to business goals. Investment decisions are not solely based on costs but rather on improving service provisioning. Whether an IT system is a cost center or a service center depends on the organization. In this way, an IT system can be considered as a service center for the one organisation and a cost center for the other. For example service characteristics such as minimize downtime and improve reliability can also be considered as performance metrics. The main question in the service center category is whether an IT system gives the organization a competitive edge and differentiates the organisation from its competitors. So the purpose of use of an IT system is important and not the application and functionality in itself. From a service center perspective an organization should look at the degree that an IT system contributes to customer acquisition and retention.

Investment center

The investment center has a future orientation. It focuses on innovations, for example creating new business capabilities by means of IT. This requires more than IT. New business capabilities are created with a unique combination of structure, processes, systems and expertise. Investment centers should focus on more than technology. Next to IT investments complementary investments will be needed to realise a business capability. That is, IT investments become part of a total package. Investment center involves resource allocations based on strategic redirection and reliance on IT for business innovations. The real options approach fits with the investment center rather than traditional financial metrics, since the real options approach takes risks and uncertainties into account. The investment center should be run as a venture capitalist. It requires the forward look of a business innovator.

Profit center

The profit center has a focus on delivering IT products and services in an external marketplace. Next to financial benefits the intangible benefits should also be taken into account in investment decisions. The profit center needs an external, marketing orientation, instead of an internal captive monopoly. The profit center should work in value networks and partner with other companies in combining complementary skills and resources to deliver value.

Operating model

Next to the commercial strategy that is chosen for IT operations, as outlined in the previous sections, we also need to take into account the more operational aspects of the organization in defining an IT planning and valuation approach. As Ross, Weill and Robertson (2006) show with numerous case studies, successful enterprises employ an ‘operating model’ with clear choices on the levels of integration and standardization of business processes across the enterprise (Figure 3):

  1. Diversification: different business units are allowed to have their own business processes. Data is not integrated across the enterprise. Example: diversified conglomerates that operate in different markets, with different products.

  2. Replication: business processes are standardized and replicated across the organization, but data is local and not integrated. Example: business units in separate countries, serving different customers but using the same centrally defined business processes. Example: a fast food chain replicating its way of working through all its local branches.

  3. Coordination: data is shared and business processes are integrated across the enterprise, but not standardized. Example: a bank serving its clients by sharing customer and product data across the enterprise, but with local branches and advisers having autonomy in tailoring processes to their clients.

  4. Unification: global integration and standardization across the enterprise. Example: the integrated operations and supply chain of a chemicals manufacturing company.

This operating model should fit both their area of business and their stage of development.

Ross et al. explain the role of enterprise architecture as the organizing logic for business processes and IT infrastructure, which must reflect the integration and standardization requirements of the operating model. For example, ERP systems are used extensively by companies that have a unification strategy, since these systems are well-suited for both sharing data and standardizing business processes across the enterprise. In a diversification scenario, however, investing in an ERP system might be a wrong choice, since the varied collection of business processes and localized data do not lend themselves to the ‘one size fits all’ approach of such a system.

Figure 3. Operating models (Ross et al., 2006).

Next to this operating model, they provide a stage model of the architectural development of organizations:

  1. Business silos: every individual business unit has its own IT and does local optimization.

  2. Standardized technology: a common set of infrastructure services is provided centrally and efficiently.

  3. Optimized core: data and process standardization, as appropriate for the chosen operating model, are provided through shared business applications (e.g. ERP or CRM systems).

  4. Business modularity: loosely coupled IT-enabled business process components are managed and reused, preserving global standards and enabling local differences at the same time.

  5. Dynamic venturing: rapidly reconfigurable, self-contained modules are merged seamlessly and dynamically with those of business partners.

In practice, most companies are still in stages 1–3. Investment decisions should be guided by the chosen operating model and the current and desired stage of an organization. E.g. if an organization wants to move from stage 1 to stage 2, the focus should be on standardizing and centralizing IT infrastructure in order to achieve efficient operations. The contribution of IT systems and projects to achieving the desired stage, in concordance with the chosen the operating model, should be a core criterion in valuating these systems or projects.

Another reason for using enterprise architecture in investment decisions is that it provides a coherent view of the various dependencies between IT systems and of their contribution to business processes and services, and hence of the broader effects of a localized IT investment decision.

Describing business requirements

Knowing what the overall IT strategy and resulting operating model is, is only a first step. Next, we have to make these strategic choice more concrete and define the resulting business goals and requirements are. Business requirements management denotes the early phase of the requirements management process that is concerned with the identification, description, analysis and validation of requirements at business level and their realization in enterprise architecture. These requirements are a reflection of the business strategy and provide a concretization of this strategy.

A desired organizational and/or technical change requires the investigation of the stakeholders that are involved and their concerns regarding the change. New goals and requirements are identified, or existing ones are changed, to address these concerns. Analysis of these goals and requirements is needed to guarantee consistency and completeness, and to propose one or more alternative architecture designs that realize the goals and requirements. Validation of these alternative designs aims at assessing their suitability and selecting the best alternative.

In this way, business requirements capture the motivation and rationale behind (the design of) enterprise architectures. Furthermore, architecture artifacts, such as business services, processes and supporting software applications, are related to the (high-level) goals and requirements they originate from. Or put in another way, goals and requirements can be traced towards the architecture artifacts that realize them. This traceability between goals and requirements on one side and architecture artifacts on the other side is important to valuate these artifacts. In the context of this work, the valuation of artifacts that represent or require IT support is of particular interest. The valuation of some artifact in terms of the allocation of costs and benefits may largely depend on the goals and requirements to which the artifact contributes.

Problem chains

Requirements engineering (RE) is concerned with the process of finding a solution for some problem. This concern can be approached from a problem-oriented view, which focuses on understanding the actual problem, and a solution-oriented view, which focuses on the design and selection of solution alternatives.

Problem- and solution-oriented requirements engineering can be considered as two consecutive or complementary phases. Iterations of these phases may be applied to address a problem progressively, i.e., in multiple, successive steps. From this perspective we can identify so-called problem chains, where each chain links a problem to a solution such that the solution is considered again as a problem by the next chain. For example, a business analyst may investigate a business problem and specify a business solution for this problem. This new solution may require IT support, therefore becoming a problem for the IT analyst. Figure 4 illustrates the notion of problem chains.

Figure 4. Problem chains

Problem chains link requirements engineering to enterprise architecture. This is illustrated in Figure 5. The why column represents the problem-oriented view and defines the business needs, goals, requirements and use-cases that should be addressed. The what column represents the solution-oriented view in terms of enterprise architecture artifacts, such as services, processes and applications. These architecture artifacts define what the enterprise must do to address the business needs, goals, requirements and use-cases. At the same time, these requirements engineering artifacts motivate and justify why the enterprise architecture is defined the way it is.

Figure 5. Relation between requirements engineering and enterprise architecture

Requirements management and enterprise architecture

Following the idea of problem chains enables an iterative way of working. Given some problem, the first step is to analyze the problem and elicit goals and requirements that address the problem. These goals and requirements are represented by a requirements model. The second step is to conceive a composition of products, services, processes and applications that realizes the goals and requirements. This composition is represented by an enterprise architecture model. Both steps can again be repeated for (the problem of) realizing the elements of the architecture.

Figure 6. Relation between requirements and architecture models

Figure 6 illustrates the relationship between requirements and architecture models, and indirectly, also the relationship between the requirements management and enterprise architecture processes. These processes are typically divided into distinct phases, which results in a series of requirements and architecture models such that models in succeeding phases refine models from preceding phases (as represented by the dashed arrows). For example, Figure 6illustrates a process of two phases: the design and realization of some enterprise architecture.

Requirements engineering cycle

The idea of problem chains distinguishes two views on an architecture model: (i) as a design artifact that represents a solution for some design problem, and (ii) as a frame of reference that delimits the design or solution space. These views are illustrated in the left part of Figure 7.

Figure 7. Views on an architecture model

In general, requirements engineering starts with some organizational goal that needs to be addressed. This issue cannot be approached ‘from scratch’, but has to take the current organization into account, as represented by architecture model A1. This means that any requirement or goal in requirements model M should be defined ‘relative’ to architecture A1 in order to address the change. In this situation, architecture A1 acts as a frame of reference for (problem-oriented) requirements engineering. Subsequently, a new architecture A2 is designed that realizes a solution for the requirements and goals in model M. In this situation, architecture A2 is considered a design artifact that results from (solution-oriented) requirements engineering.

The right part of Figure 7depicts a further decomposition of requirements engineering into three steps:

  • Problem investigation, which focuses on the problem, i.e., the organizational change, by identifying and analyzing its cause in terms of the involved stakeholders and their concerns, and by setting goals to deal with the change.

  • Investigate solution alternatives, which refines the goals in order to find possible solutions to realize them. Analyses are performed to reveal conflicts between (refined) goals or contribution relations between goals in which goals contribute positively or negatively to other goals. Typically, these analyses trigger the identification and elaboration of alternative solutions.

  • Solution validation, which validates alternative solutions and chooses the ‘best’ among them. This choice is amongst others influenced by the conflict and contribution relations that have been identified.

These steps constitute a generic requirements engineering cycle that can be repeated at successive phases in the development of some enterprise architecture, as indicated by the dashed arrows in Figure 7. Furthermore, the identification, analysis and refinement of solution alternatives in the second step may be repeated as well, leading to ‘sub-cycles’.

In Quartel, et al. (2009), a method and modeling language, as an adjunct to the ArchiMate language (Lankhorst et al., 2009), have been presented that support business requirements management as outlined above. In this paper, we will not go deeper into this topic, but merely use these ideas in an example below. The interested reader is referred to the aforementioned publication.

Computing aggregate IT valuations

In the previous sections, we addressed the business strategy and requirements that provide the context for determining the value of an organization’s IT portfolio. In the context of our method, the value of the IT portfolio is related to the way in which IT projects and applications support these strategic goals and requirements. To assess such a portfolio, the contributions of its various elements to the goals of the organization must be determined. Note that this method does not provide a direct link with the effects of IT projects, and hence of the organization, on the outside world; rather, it assesses the contribution of the IT portfolio to the organization’s goals, which in turn may contribute to such external effects.

A contribution can be divided into two elements: its importance to a business goal and the quality or effectiveness in supporting that goal. The value of an organization’s IT portfolio thus depends on the contribution that its constituent elements provide to the business.

An interesting and useful way of computing an IT portfolio’s value based on these business contributions is Bedell’s method (Schuurman et al., 2008). This method answers three questions:

  1. Should the organization invest in information systems?

  2. On which business processes should the investment focus?

  3. Which information systems should be developed or improved?

The underlying idea of the method is that a balance is needed between the level of effectiveness of the information systems and their level of strategic importance. Investments are more crucial if the ratio between the effectiveness of an information system and its importance is worse.

In order to calculate this ratio, the following information needs to be determined:

  • The importance of each business process to the organization.

  • The importance of information systems to the business processes.

  • The effectiveness of the information systems to the business processes.

Based upon this information, three portfolios are calculated: for the organization as a whole, its business processes, and the information systems that support these processes. Figure 8 depicts an example of all three portfolios and associates a general investment decision to each quadrant of the portfolios. A dashed arrow points to the ideal position of some organization, business process or information system (IS) in the portfolio.

Figure 8. Investment portfolios

The prioritization of investment proposals is determined by the contribution of each information system, which is defined as the product of its importance and the projected improvement of its effectiveness. In addition, the value of the investment can be evaluated by calculating a so-called project-return index. This index relates the contribution of the information system to the development costs.


Bedell’s method is well-suited to be used in combination with enterprise architecture models. Figure 9depicts the architecture elements on which the method operates: a business actor that represents the organization as a whole, the business processes of the organization, the activities that are performed by the business processes, and the information systems that support these activities. The architecture elements are represented in the ArchiMate language (Lankhorst et al., 2009).

For convenience, the ‘used by’ relation is used to relate the architecture elements, except for the aggregation relation between an individual ‘Information system’ (represented as an application service) and the collection of (all) ‘Information systems’. As noted before, Bedell assumes the following restrictions on the architecture model: (i) a business process may comprise multiple business activities, but a business activity contributes to only a single business process, and (ii) a business activity is supported by a single information system (represented as an application service), and an information system supports only a single business activity.

Figure 9. Bedell’s method and enterprise architecture

The names that are annotated to the ‘used-by’ relations in Figure 9 represent the variables that need to be determined as input to the calculation of the investment portfolios as depicted in Figure 8:

  • IBO = the current Importance of some Business process to the Organization;

  • IAB = the current Importance of some Activity to some Business process;

  • IIB = the potential Importance of Information systems to some Business process;

  • ESA = the current Effectiveness of some Information System to some Activity.

Plotting portfolios

The information obtained from computing these indicators can be shown graphically, as illustrated by the figure below. This type of plot is familiar to anyone who knows the business value – technical value diagrams used by, for example, the ASL methodology, in particular its Application Lifecycle Duration Measurement Method (ALMM).

Figure 10. Example of an activity level portfolio

Figure 10depicts an example of an activity-level portfolio. The importance of an activity to a business process is represented by variable IAB at the y-axis. The effectiveness of a single information system in supporting an activity is represented by variable ESA at the x-axis. Similar plots can be made at the business process and organizations levels.

In Bedell’s method, an information system is considered effective when it is cost-effective, has high technical quality and is functionally appropriate. It is considered strategically important when the activities it supports are crucial to a business process or the organization in obtaining its strategic objectives. The prioritization of investment proposals is determined by the contribution of each information system, which is defined as the product of its importance and the projected improvement of its effectiveness. In addition, the value of the investment can be evaluated by calculating a so-called project-return index. This index relates the contribution of the information system to the development costs. However, the determination of all these variables is rather subjective and lacks concrete guidance. Hence, we need more concrete measurements of the properties of the IS landscape.

Tool support

The input variables IBO, IAB, IIB and ESA can be defined as attributes of the used-by relation in an ArchiMate enterprise architecture model. This allows one to calculate the portfolios of Bedell’s method automatically. For this purpose, the BiZZdesign Architect tool has been extended with a valuation profile for Bedell’s method and a viewpoint for each portfolio. Figure 11 depicts part of the example from (Schuurman et al., 2008) as modeled in ArchiMate. In addition the figure shows the profile properties in the Architect tool that are used to represent the Bedell variables, including the labeling of some of the architecture elements with the values of the properties.

Figure 11. Valuation profile for Bedell’s method

The portfolio viewpoints calculate the values of the variables at the axes of the portfolios as explained before. This information can be shown in a table (Figure 12) or in graphical form (Figure 13).

Figure 12. Business process portfolio in BiZZdesign Architect

Figure 13. Business process folio in Excel

Expressing and assessing value

For assessing an IT portfolio, specific measures are needed as input for decision making. These measures or KPIs should be derived from the business goals. Bedell’s method uses ‘importance’ and ‘effectiveness’ as major criteria, which are both single measures related to an application or business process. The notion of ‘effectiveness’ (or rather ‘quality’) is broad and it depends on the value center approach that the organization chooses. For a service center approach, for example, customer satisfaction is an important criterion; the effectiveness with which a system supports this may depend more on aspects such as usability. For a cost center, low maintenance and efficient usage of resources is important, and for an innovation center, flexibility of a system is essential to obtain an effective support of future capabilities.

Although the scope of the concept of effectiveness is large, the various views can all be related to concepts of IT quality that are addressed in the ISO 9126 standard for software quality (ISO/IEC, 1991). Although this standard was originally intended for classifying various types of requirements posed to a system before it is built, the attributes can also be used to assess its qualities after it has been constructed.

The notion of ‘importance’ is more difficult to address. Although methods such as ASL [Van der Pols & Backer, 2006] provide questionnaires to investigate the business value of applications, much of this value is dependent on, for example, the value of the information a system provides to the business, the value of future opportunities opened up by IT, or the value of customer satisfaction created by a user-friendly system. A future project phase might pay more attention to these types of value assessments.

One important category of indicators related to importance addresses risk. Risk in general is one of the criteria on which managers base their investment decisions. ‘Risk’ is often defined as the effect of uncertainty on business goals (e.g. in the ISO 31000 guide (ISO, 2009)). In the value center approach, ‘risk propensity’ is an important factor in the type of value center. The cost and service centers aim for low-risk operations, whereas the profit and investment centers allow for higher risks in order to obtain possible (but uncertain) gains from future business opportunities. There are also risks concerned with failure of projects.

To provide the connection between the IT strategy and value center approach, we have investigated a first mapping between the four value centers and the specific indicators that are most relevant for these centers. Further research is needed to come up with concrete indicators that can be used within the context of the method outlined in the previous sections. Furthermore, decision making, whether the decisions apply to IT or not, is rarely performed under conditions of complete certainty. We will have to deal with these uncertainties and the risks associated with these decisions. Bayesian networks (Johnson et al., 2007) are an established mathematical technique to deal with uncertainties in networks of dependencies like enterprise architectures.

Another challenge is dealing with imprecise measures. If one asks an expert or managerial opinion on a qualitative aspect of an IT system, his or her answer is often expressed in rather vague terms, for example: ‘this system is rather good’, ‘this business process is very important’. But what does ‘rather good’ or ‘very important’ mean? Techniques such as fuzzy logic (Zadeh, 1965) could be used to express and reason about such terms.

Putting it all together

If we put all the elements described in the previous sections together, we arrive at the figure below. The value of an artifact or project is determined by its contribution to the achievement of business goals. Its contribution is loosely defined by ‘importance x quality / effectiveness’ of the artifact. Business goals are translated into (operational) requirements on the enterprise architecture and into the structure of its operating model, and further refined into KPIs for the artifacts. ‘Importance’ can be determined by assessing the ‘strength’ of the relations between the business goals and the artifacts. ‘Effectiveness’ or ‘quality’ is determined by measuring the identified KPIs. Based on these measures of importance and effectiveness, we can then determine the value of the artifacts.

Decision making and evaluation of alternatives based on the valuation of an IT portfolio will require an assessment of multiple aspects. An obvious case is the combination of financial aspects (e.g. direct cost, TCO, ROI, NPV) in relation to measures of business and technical value or effectiveness and importance, as described in the previous sections. Established financial instruments such as TCO or ROI calculations do not use the architectural structure and dependencies but do their computations only on the individual elements present in the portfolio. The outcomes of these techniques should of course be taken into account in making IT investment decisions.

Each of these techniques results in some assessment or valuation. These results alone are of course not enough. Given an assessment of the cost, returns and qualities of different alternatives, for example renovating an application, replacing it completely, or leaving it as-is, how can the organization decide upon such a multitude of inputs?

Rather than use a separate method for each of these assessments and combining the results by hand, our ultimate goal is to develop a flexible plug-in architecture for architecture-based valuation methods, in which different criteria can be combined using a central framework for multi-criteria analysis. Our aim is to provide an integral approach that can be implemented in tools for architectural design and analysis, to provide optimal support for architects and IT managers.

Moreover, using these techniques as part of the architectural design process, the value of using enterprise architecture as a foundation for decision making is strengthened. Different design alternatives can be assessed on their contribution to business value and well-informed decisions can be made that take the enterprise-wide effects of changes into account.

In the next phase of our project, this method will be fleshed out, implemented and tested in one or more real-life cases to validate it in practice. Furthermore, indicators for judging business value in a more concrete way might be researched in more detail, for example to quantify the value of the information a system provides to the business or the role it plays in satisfying customers. Finally, a topic of further study might be the applicability of the method in the context of service portfolio management and service-oriented architecture, where services instead of entire applications are the units of management and valuation.


This paper results from the ArchiVal project, a collaboration between Novay, the Dutch Tax and Customs Administration, and BiZZdesign, aimed at developing architecture-based methods for IT portfolio management. For more information:



Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura



Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden