Methodological Basics of Localization During Business Software Development

Andrej Danko METHODOLOGICAL BASICS OF LOCALIZATION DURING BUSINESS SOFTWARE DEVELOPMENT 1 Introduction Enterprise application software supporting the everyday operations of a company s functions and providing tactical and strategic reporting for relevant management structures is nowadays a standard foundation of firms. The influence of globalization on the dependency of individual countries and regions as well as changes in legislation and the pressure to harmonize accounting standards (accounting rules, reporting) with international norms has resulted in new requirements for business software vendors. In the first place, it is necessary to take into consideration the local needs of a target country (or a set of countries) for which the software is intended and at the same time have a sufficiently flexible design that provides the ability to adopt the software to changing needs. In this article we aim to describe selected methodological basics of localization that are suitable for adoption during development of standardized enterprise applications. We focus primarily on the analysis phase, which is critical from the software lifecycle perspective and determines the correctness of the following phases; however, we also suggest several design aspects from which the analytical phase can source. In this article we have synthesized a basic understanding about the aspects that need to be considered during localization it is not our aim to answer the question of how to obtain the necessary inputs. These basics are a result of a multi-year analysis and synthesis during the development of standardized enterprise software for 40 countries world-wide during which such requirements were an inseparable part of the development process. In the context of methodological basics we build on the defined globalization components during software development, described in (3). 1 BASIC PRINCIPLES AND PROCEDURES During the development of enterprise software we build on basic principles, which are structured and object oriented (OO) approaches for software analysis and design (9, 11). In the context of this article, we define enterprise software applications, such as ERP, CRM, SCM, etc., applications that are intrinsically localization relevant. The modules that are most influenced by localization are accounting (e.g., general ledger) and reporting (e.g., sales reports in the context of movement of items in the EU region), logistical processes of sales and purchasing, payments and banking, stock accounting, production, etc. In general we will refer to these modules as applications. DANKO, Andrej: Metodologické základy lokalizácie pri vývoji podnikového softvéru. () In Ekonomika a Informatika (Economics and Informatics) : Scientific Journal FHI EU in Bratislava and SSHI. - Bratislava : Faculty of Business Informatics : Slovak Association for Business Informatics, 2009. ISSN 1336-3514, 2009, volume 7, no. 1, pp. 8-27. Originally published in Slovak language. http://sekarl.euba.sk/arl-eu/en/detail-eu_un_cat.1-0107490-metodologicke-zaklady-lokalizacie-privyvoji-podnikoveho-softveru/ 8

During software development, many approaches, techniques and methodologies are used. We define methodology as a set of methods and techniques elaborated into a set of concrete work steps resulting in a full solution of the given problem. It is a description (guide) for a solution of a more complex task involving organization of work steps and assignment of methods and techniques to these steps. We define method as a knowledgeable set of steps during an activity or execution, through which we derive from known facts and knowledge new facts and knowledge. A technique is a specific form of a method s application to solve a specific set of problems that can be solved by applying that method. A methodology represents a union of methods and techniques and supporting instruments applied to solve a specific class of tasks (12). 1.1 Terms and Definitions Used to Define Methodological Basics of We define Globalization as the process of applications development in such a way that ultimately enables the supply of these applications to more countries. Standard components of globalization are internationalization, localization and translation. We define Internationalization as an architectural concept of application that creates a suitable environment and enables application localization i.e., an application designed with a concrete layer of internationalization enables application localization without further architectural changes. We define as a process of application modification in such a way that it reflects differences resulting from various legal, business parameters as well as the customs of individual countries (3). From the perspective of application analysis and relevancy for localization we define the following set of data elements (derived from 11): Data Entity representing a certain type of data the system operates with. Examples are an account of a chart of accounts, address, invoice, etc. Data Relationship representing the binding between data entities. Examples are the relationship between the invoice and the billing address or an invoice and its accounting posting. Attribute is part of a data entity and represents an atomic data element. Examples are a phone number, the sum of value added tax on a document, etc. An instance of a data entity, relationship or attribute is a concrete value relevant to the described object. Data entity Data relationship Attribute Relationship between data entity, relationship and attribute From the functional perspective, we define the following set of functional elements that are relevant from the localization point of view: We define Business Function as an atomic operation with a defined set of inputs and outputs in the form of attribute instances whose purpose is a transformation of 9

these values based on a defined algorithm. Examples are a function that validates the correctness of the tax identification number input on a screen. We define Business Transaction as a defined set of processing by creation, modification or transformation of one or more data entity instances (composed of a set of business functions as well) using a set of inputs (whether from a user or using other data entity instances triggered by a concrete event). An important aspect of a Business Transaction is its time consistency, i.e., the inability to divide execution of a transaction to a set of individual operations in time. The outputs (of Business Transitions) are new or modified instances of defined data entities. Examples are the issuance of a concrete invoice (on the basis of an order or delivery or based on a user s inputs) and the related posting entry in the general ledger. We define Business Process as an ordered set of two or more Business Transactions, the execution of which results in a realization of a specific business goal (in addition to the result of individual Business Transactions). Examples are the Order-to-cash Business Process or the Down Payment Business Process. Business Process Transactions [*]: Business Transaction Business Transaction Input [*] : Data entity Output [*] : Data entity Define set of processing () Business function Input [*] : Attribute Output [*] : Attribute Algorithm () The relationship between business function, transaction and business process The analysis phase is critical in the context of requirements definition for software implementation (design and coding) and is influenced by the fact that its inputs are defined either by incomplete requirements of future users or the inability of the complete understanding of all relevant facts during the analysis phase itself. This factor plays an important role predominantly during enterprise software development, which has to cover various legal requirements and fulfill international standards as well, some of which are complex; and it is fairly complex to determine its influence on individual business functions, transactions and business processes. From the functional perspective, localization influences its two elementary components: data structure and function. Whereas within a data structure the elaboration of methodological procedures is inadequate, within the functional view there exists at least a limited set of theoretical basics. 10

1.2 Impact of on Data Modelling The data modelling component of the analysis is nowadays being derived from analytical patterns, which help to describe the nature of the described domain. They are an inseparable part of the software analysis and therefore we consider them appropriately. We demonstrate localization on a simple analytical pattern, where it is our intention to show how localization influences various aspects of data modelling for example, abstraction. The foundation is a sample of class entities Person, Man and Woman, and their relationships (11, page 14), which are defined as follows: Person Civil Union 0.. 1 0.. 1 Man Army Service { or } Woman 0.. 1 Marriage 0.. 1 The shown analytical pattern defines class Person and its specialized classes Man and Woman. Between a Man and Woman, there is either a Civil Union or Marriage association, and in the context of their multiplicity, Man or Woman can be only one partner (Civil Union) or husband/wife (Marriage). We also defined a mandatory attribute Army Service for the class Man, which defines the duration of army service. This analytical pattern is correct and comprehensive from a certain local (country) perspective at a certain time, whereas in looking at other countries and legislation as well as its time validity, it becomes inaccurate. Doing a global analysis we identify that Civil Union or Marriage can be in certain countries between Persons of the same sex, so the defined associations must be transferred to the generalized class Person (recursion). Its multiplicity can be also questioned, because in some Middle Eastern countries it is possible that one Man has multiple Civil Union or Marriage associations. Finally, the attribute Army Service evolves in time (i.e., class Man had this attribute but today is not valid any more) and in some countries (for example, Israel) Army Service is mandatory also for women, so the attribute should be transferred in the context of generalization into the class Person. Applying the described facts, we generate a modified globalized analytical pattern, which encompasses localization influence of the different data diagram elements: 11

Marriage Civil Union 0..* 0.. 1 { or } Person Army Service 0.. 1 0..* Man Woman Giving this simple example we demonstrated that regionalism or globalism increase data modelling complexity. To manage them, however, it is necessary to give them appropriate attention. Enterprise applications and their modules, which must be compatible with different countries and their laws, best business practices and customs, cannot ignore the importance of related changes during the analytical phase. 1.3 Theoretical Definition of from the Functional Perspective 1.3.1 Analytical View Let the term Business Algorithm Category (T) define one or more algorithms implementing a certain business rule (4). Such a category can be algorithms to calculate row value added tax (sales tax VAT), VAT in rows with the same tax group or calculation of VAT for the whole document. Another category can be methods to handle rounding of cents, in one instance for tenths of cents rounded up, in another instance rounded arithmetically, or for fiftieth of cents rounded arithmetically. The result is that each algorithm from its category of business algorithms has the same characteristics, but each category of algorithms is disjunctive. (T1, T2,..., Tn) : T We can also assume that particular localization for a certain Localized Unit 2 or simply localization (where we consider a Localized Unit/localization as atomic and non-dividable) is defined by a set of algorithms from different Business Algorithm Categories. For simplicity, let us have two Business Algorithm Categories, T and T, for which the following will be true: (a, b) : T (α, β) : T 2 Typically, a Localized Unit is one country, but for certain jurisdictions (e.g. USA), the given unit can be broken down to smaller units (e.g. states). 12

Next, let us have three Localized Units, for which we will define particular localizations: Category Localized Unit T T L1 a α L2 b α L3 b β The definitions above implicate that, e.g., when Localized Unit L2 activates algorithm T, it uses its localization b and for T its localization α. This basic definition is on an elementary level for an algorithm, which does not cover even remotely the complexity of the analyzed domain. Algorithms are only one part of the complete functional (and data) framework, which we defined, and therefore it is necessary to extend the given methodological foundations for additional elements (Business Transactions and Business Processes, as well as elements of data modelling). 1.3.2 Design and Implementation Views One possible solution to implement the defined localizations is to use the traditional structured programming approach (4): if ( legalunit == L2 legalunit == L3 ) { b } else { a } // default if ( legalunit == L3 ) { β } else { α } // default This approach has many deficiencies. The above-mentioned code fragment implies that implementation of a wider business logic and its localizations for different countries can become very complex and in the end unclear and hard to maintain. We have to remark, however, that in a professional context it is still the most used one (because of its initial ease of use and implementation), but causes severe issues during source code maintenance and further development (in terms of extension or change). Using the above-mentioned implementation approach, the differentiation between the generic (globally) valid business algorithms and the locally valid ones dissolves; information about which set of individual algorithms from which categories define a Localized Unit for each legislation is lost. Another possible approach to implementing the given Localized Unit is to use OO approaches leveraging polymorphism. This can be designed by defining a class hierarchy and distributing implementation of algorithms a, b, α, β between the defined classes, which invoke the particular algorithms: 13

L1 a() α() L2 b() L3 β() This results in a model, which for particular class L1, L2, or L3, representing in this case individual Localized Units, invokes the appropriate algorithm, relevant for the particular localization. Analyzing the model in detail, we realize that for a more complex case, a model of this particular class implementation design would become very complicated and even illogical, because we would need many classes with different and duplicate generalization and specification associations. Another possible way is to integrate an aspect oriented programming paradigm and the concept of aspects, which would enable implementing additional code fragments at the end of which the program flow would return to the originating place. This method is difficult to realize, however, because it is impossible to know beforehand all the places in the code where the code needs to be modified or extended. Another possible approach is based on algorithm externalization from within the programming code or classes into separate parts and connecting (or polymorphing) them into a class instance according to their need in the context of localization requirements during the compile or execution time of a program (depending on static or dynamic definition of their connection). Particular Object a c b One of the possible ways to implement the aforementioned approach (using the C language) is to use a structure containing a set of function pointers with its declarations, the value of which is implicitly set to zero and a set of functions with the same defined declaration and definition (implementation). This example in the C languages solves the particular issue; however, it is data type instable. 14

A more sophisticated solution is to use design patterns, which we demonstrate using an example (adapted from 4). The purpose of such implementation technique is to make the given business algorithm category peripheral (and therefore easily modifiable). The decision regarding which algorithm will be executed with the related data is left to another (tertiary) subject, which can be the relevant object or control/application software layer (client). Furthermore, an additional advantage resulting from such an approach is the decoupling of data classes representing business entities from the knowledge of how to execute certain business algorithms for a set of Localized Units. As an example, we demonstrate the above-mentioned using a simplified model of invoice (containing elementary business definition) and calculation of VAT for that invoice in three different ways. Attribute VAT Group of Invoice, Invoice Item, and Customer classes contain a percentage value of VAT based on the method used to calculate VAT using: VAT of individual items of the invoice, the total value of invoice multiplied by the percentage value for a certain country, the total value of invoice multiplied by a percentage value for a given customer (who is from a state where VAT is different). Invoice Item Amount Price VAT Group Invoice Vat Group VAT : VAT SetVAT ( in VAT : VAT ) Name Item Customer VAT Group Simplified Invoice Class Diagram To implement the above-mentioned technique of peripheral business algorithms, combined design patterns Strategy (8, page 315) and Factory (8, page 107) are used. They are described in depth in the cited literature (8, pages 316, 108); therefore, we describe hereinafter only the reason for its usage and structure relevant for this example: Strategy large set of related classes differentiated by behavior only. Design pattern Strategy offers a proposition for how to configure a class with one of the many behaviors: 15

Factory certain class cannot predict the class of objects it has to instantiate: Continuing the example of invoice VAT calculation, the base of the design is the VAT Calculation Strategy, which serves as a standard interface for VAT calculation. Invoice VAT Group VAT : VAT SetVAT ( in VAT : VAT ) Client request «Strategy» VAT Calculation Strategy Calculate (in Invoice):VAT «Factory» Choose Strategy Choose (): VAT Calculation Strategy Fixed VAT Customer Based VAT Row VAT Calculate (in Invoice):VAT Calculate (in Invoice):VAT Calculate (in Invoice):VAT VAT Tax = Choose Strategy :: Choose (). Calculate ( Invoice ); Invoice. Set VAT ( Tax ); Classes Fixed VAT, Customer Based VAT, and Row VAT are specifications of the abstract class VAT Calculation Strategy and implement relevant algorithms of VAT calculation contained in the Calculate() method (which belongs to the Business Algorithm Category). Next, public class Choose Strategy is defined, implementing a static method Choose(), which gives the Client a memory pointer to the method implementing VAT calculation relevant to the context. In this example the context (and strategy) is given according to the client runtime setting of the country, defined by the class Request. It is important to recognize the following with respect to the described implementation of VAT calculation using the mentioned design patterns: Class Invoice does not know the existence of more ways to calculate VAT. It provides only data that are input for VAT calculation as well as the means to set the VAT from an outside method SetVAT; Abstract class Choose Strategy is the interface for any code of the client. The decision regarding which VAT strategy implementation class is going to be used depends on this class, depending on the environment or the object s attributes; 16

The client has three choices: implementation of the default algorithm for the current environment, implementation of the algorithm for a specific environment or invoking a specific algorithm. Studying closely the above-mentioned approach, there are several challenges related to the described technique to implement localization, such as: divergence from OO approach in the sense of decoupling data (in this case VAT) from its methods (VAT calculation), higher design complexity (though compared to the described structural approach more transparent and maintainable), the need to duplicate programming code in case there is larger or smaller amount of source code within the individual algorithms within a set of business algorithms. 1.4 Language Aspects of of each product (i.e., including software) requires the ability to understand each of its parts interacting with end-users in the language of the given Localized Unit. In many countries, the availability of language mutation is legally binding. Therefore, it is an inseparable part of product localization. We can categorize language localization of software products based on whether it has extensive, minimal or no influence on its architecture. Components with extensive influence are: language mutation of user interface, the ability to store name of items (most common are attributes of different classes) in different languages (see more in detail in 10, page 11), the ability to print reports and documents in the language of a Localized Unit, printing of documents (for example, an invoice) in the language of a business partner (in the case of a foreign business partner), the availability of default values in the language of a Localized Unit (i.e., the initial configuration of the system, for example, the names of accounts in the chart of accounts). Components with minimal influence are: process and functional product documentation, procedures and methods (for example, installation manuals), methodological artifacts (for example, chosen best business practices). During the analysis phase of a software s lifecycle, it is important to define which of the components with extensive influence it is necessary to incorporate into the holistic data and functional models. Whereas some of the components influence only the design part of the software lifecycle (or the development environment and supporting tools), others influence the analysis phase as well. Examples from data modelling are string attributes that store values describing, for example, names of warehouse items, names of payment terms, etc. An example from functional modelling is a Business Function implementing printing of any monetary value in its textual string representation in a concrete language. Lastly, the tools and means to ensure translation of elements (created by the developer of the software product) are important, as well as their integration into the lifecycle of development. Individual components are usually consistently created in a selected language 17

(usually in English), and then, following a defined process, exported from the development environment (of the software or documentation) to tools enabling their translation and subsequent import into the development environment. An important factor of this process is the translation context, which needs to be preserved during the translation cycle, especially during the translation process itself (i.e., the influence of the context of a translated element on its meaning and the related correctness of the translation of the element, which has to be semantically identical with the original meaning of the element). 2 DESIGN OF FUNDAMENTS OF LOCALIZATION METHODOLOGY As it is evident from the above-mentioned analysis of the state-of-the-art of the software localization domain, the localization methodology must consider data and functional views as well as different levels of aggregation within them. Therefore, in the fundaments of the methodology we are going to focus on the following selected aspects: data attribute, association (relation) and class, and factors that must be considered during localization as well as possible solutions, Business Function, Transaction and Process, where we are going to build on top of the definitions of business algorithms and show particular differences in the context of localization. In the context of modelling steps, in the first step it is possible to create a data model, which reflects the needs of localization as well as directs the definition of a functional model. An example is the need to maintain compatibility with a certain attribute structure (see below), validation of which must be ensured by a business algorithm. This example indicates (as well as real-world experiences, as stated in example in 11, page 5), that the key part of the architecture is its data component. Nevertheless, the functional elements are also important during localization, because they represent the core of business logic, which must be executed in the context of different localizations, based on data structures. Therefore, it is possible to follow the top down approach, where relevant Business Processes, Transactions and Functions are identified, which are relevant for a particular localization, and subsequently one continues with the design of the data model. From an organizational perspective, the composition of team, individuals of which are modelling data and functional parts of the system, is important. Depending on the object being modelled (particular system component), it is important to choose subjects participating in the modelling. Firstly, experts from the domain part of the system being modelled are needed. An example is accounting and auditing, where the general knowledge of accounting is necessary as well as knowledge of specific aspects of Localized Units, for which the localization is being implemented. Next, experts from the data and functional (process) modelling parts (Product Managers) are needed, who are able to transform requirements from the domain experts into related analytical models, which serve as the foundation for a system design and its subsequent implementation. Product Managers are the target audience of the proposed methodological basics of localization, for whom these serve as guidelines for the design of particular models. Lastly, software architects should also be part of the team, who are able to assess the feasibility of the designed analytical models in the context of a concrete development environment or its interoperability with existing software systems or other related systems. In 18

the proposed methodological basics of localization, we will exclude the influence of language localization (described in section 1.4) on particular analytical models, in order to focus on the core basics of localization, which is central from our point of view. 2.1 Basic Concepts of Data Modelling When identifying differences in data modelling, it is necessary to consider several aspects related to localization. In this context, we will enumerate the elementary aspects, describe them succinctly, provide an example, and emphasize what is important to consider from the localization perspective as well as provide a set of solution steps methods that can be applied. 2.1.1 Data Entities and Data Associations (Relations) Existence in the context of a Localized Unit Description Example Set of possible solutions Identifies whether a given data entity is needed in the Localized Unit. Correction Invoice (for example, required in Poland; in other countries Credit Memo is sufficient), Tax Invoice (special type required, for example, in Russian Federation). Certain Localized Units require specific, new, or derived entities, which represent certain concrete requirements resulting from legislation. 1. Create new data entity with parameters and relevant associations with other data entities. 2. Create new data entity using means of specialization from existing data entities (applying parametric polymorphism, etc.). 3. Create new data entity through generalization of an existing data entity with separate generic (valid for a set of Localized Units) attributes; subsequently create specialized data entities, from which the first fulfills the original scope and the second the scope of a given Localized Unit. Modelling of data entities in relation to localization is the most important aspect of the whole design of an application s data model. In generic terms, one needs to apply principles of abstraction, aggregation and flexibility; however, the issue of unknown differences at the time of modelling still persists, as well as the issue of change in time (for example, because of legal changes). Multiplicity Description Example Set of possible solutions Identifies multiplicity between the analyzed data entities. Exchange rate differences related to open documents (for example, invoice). In certain Localized Units, 1..n relation exists (for more open documents there is one aggregated exchange rate difference), in others n..n (for more open documents there are more exchange rate differences). 1. Define the maximum multiplicity taking into account the whole set of Localized Units. Ensure validation control of relationship creation by a business algorithm. 19

2. Create a specialized data entity and transfer the relationship from the abstract class to the specialized data entity. 2.1.2 Attribute Existence in the context of a Localized Unit Description Example Set of possible solutions Identifies whether a particular attribute in a given Localized Unit is required, not required or does not exist (is not defined). Tax Date is in some countries different from the Document Date, or Posting Date. Existence of the attribute for a (set of) Localized Unit(s). 1. Define exactly all relevant attributes of a Localized Unit even though other Localized Units do not require them (i.e., it is semantically incorrect to use the same attribute to store different values). Data Type Description Example Set of possible solutions Identifies what the value of an attribute can be, based on required occurrences in the real world (numeric, alpha-numeric, enumerations, etc.). Tax Identification Number for VAT (VAT ID), which is from a specific Localized Unit s view alpha-numeric. The difference in type (for example numeric vs. alpha-numeric) for different Localized Units, given by legislation, standards, etc. 1. Use data type that is a union of required possibilities (for example, alphanumeric in case of the need for both numeric and alpha-numeric). 2. Use overriding in case the list of types changes, or use attribute abstraction (see more in 11, pages 20-28). 3. For finite sets of values (for example, list of countries), use ISO standards or other standards, which are generally acceptable and exhaustive in their domain context. 4. De-normalize one attribute to two (indicating which Localized Unit is relevant for which), where the semantic meaning of the attributes is the same, but syntactically (data type related) different. This technique, however, creates room for error in the context of attribute usage, and therefore it is important to inspect its impact on the concrete case. Length / Size Description Defines minimum and maximum values for numeric data types, maximum length for alpha-numeric, or their combination. Example Variable symbol in payment transactions, which is in our conditions [translator s note: Slovak Republic] numeric, with a maximum length 10 digits. Difference in length (for example, 10 vs. 12). Set of possible 1. Use the maximum value from the set of acceptable values (for example, 20

solutions maximum 12) and ensure through value validation for given Localized Units (using business function). 2. De-normalize one attribute to two (indicating which Localized Unit is relevant for which), where the semantic meaning of the attributes is the same but syntactically (data type related) different (see attribute Data Type and its set of possible solutions). Value Structure Description Example Set of possible solutions Defines valid structure for attribute s values based on required occurrences in the real world. Bank account number is composed from a prefix number and an account number. VAT ID has a prefix containing a country code (for example, SK) and the identification number itself. Different Localized Units have different attribute value structures. 1. Ensure correct value structure on input using valid values verification that is correct for the given Localized Unit (using business function). 2. Split attribute to a set of attributes, from which each part will represent atomic value given by the defined structure. Relation to Data Entity Description Example Set of possible solutions Analysis of the association of a given attribute to a set of data entities and their model in the context of abstraction. Value Added Tax (VAT) for document item rows. In some Localized Units, VAT on a document (for example, invoice) level is sufficient; in other ones, VAT must be present on document item rows as well. In each design, maximize abstraction in order to create a sufficiently generic model that can be applied in different Localized Units. On the other hand, if needed, it is useful to specialize to a level a Localized Unit requires. 1. Create generalized data entity, which contains set of attributes related to all Localized Units. 2. Create specialized data entities, which contains set of attributes related to a specific Localized Unit. The influence of localization on attribute changes is multiple in many cases; i.e., it influences more than one at the same time. In such cases, it is important to consider the intersection of individual areas and choose a solution path that enables their realization in the context of optimal conditions (for example, singularity of existence of an attribute or multiplicity of an association). 2.2 Basic Concepts of Functional Modelling As we stated, functional modelling follows data modelling and creates the primary elements of business logic localization. In the context of OO approaches, behavior of data entities (i.e. classes) is encapsulated with its content (using methods). For simplification, 21

however, we will separate data layer (whose definition is primary), followed by analysis of the functional layer, which in many cases connects to the data modelling. 2.2.1 Business Process Existence in the context of a Localized Unit Description Example Identifies existence of the analyzed business process as a whole in the given Localized Unit (and process requirement within the application in relation to market segment, focus, etc.). Management of checks and bills of exchange. Some Localized Units do not require support of certain business processes; for others it is required by their respective legislations. Solution steps 1. Identify requirements of a Business Process presence in a Localized Unit, and its influence on creation or change (in the context of its domain 3 ) of: data entities, sets of Business Transactions, Business Functions and related business algorithms. 2. Ensure availability of the Business Process in the Localized Unit (in design or runtime). 3. Enable its ad hoc activation for other Localized Units in the case that, in the future, there is a need to support the Business Process. In this case it is important to consider all other aspects of this methodology, because the given Business Process required in a new Localized Unit can require alterations in the different identified areas (data and functional). Sequences Description Example Individual Business Transactions a Business Process consists of can be executed (invoked) in different sequences, and their execution is mandatory or not mandatory, based on the Business Process Definition, according to the given Localized Unit. Issue Down Payment Invoice in the Down Payment Business process. In some Localized Units all steps (Business Transactions) are mandatory; in some they can be omitted or have a different sequence of execution. Solution steps 1. Identify all Business Transactions required to fulfill the goal of a Business Process for related Localized Units. 2. Identify a generic sequence of the related Business Transactions, which is the most suitable one for all Localized Units. 3. Identify differences in execution sequences for different Localized Units, and mapping the different sequences to the context of input and output data entities and their instances, based on whether they: exist (are available when a particular Business Transaction requires them), have required state (whether required values are set for their attributes), 3 In this context domain relates to the respective Business Process. 22

2.2.2 Business Transaction create related associations (relations) if relevant instances exist, defined by associations between their data entities). Examined instances are the output (whether created or transformed by another Business Transaction) within the Business Process (for example, that the change of order does not cause non-existence of relevant inputs or incorrect, incomplete, or unprepared values). Existence in the context of a Localized Unit Description Example Existence of the analyzed Business Transaction in the given localized Unit given the requirements of identified Business Processes. Correction Invoice or Credit/Debit Memo. Some Business Transactions are required only for certain sets of Localized Units and some can be substituted by others. For example, a Correction Invoice is related to Central Europe, whereas Credit and Debit Memos are required in many Localized Units (and substitute a Correction Invoice for some). Solution steps 1. Identify the need of a Business Transaction in the context of a given Localized Unit and defined Business Processes. 2. Ensure availability of the Business Transaction in the Localized Unit (in design or runtime). 3. Enable its ad hoc activation for other Localized Units in the case that, in the future, there is a need to support the Business Transaction (see in section 2.2.1 Business Process Existence in the context of a Localized Unit Solution steps). Input and Output Parameters Description Execution of a Business Transaction is based on input processing and creation of relevant outputs (data entity instances). Example On input, instances of automated posting entries, items, business partners, etc., during Invoice creation. On output, Posting Entry, Stock Movement Entry (at stock movement), etc. Requirements of Localized Units change the structures on input and output (for example, in some cases the output of a Business Transaction is one instance of a Posting Entry; however, due to reporting requirements of other norms, two Posting Entries must be created in parallel). Solution steps 1. Identify sets of input and output data entities and changes related to different Localized Units. 2. Evaluate differences in processing an expanded or condensed number of input-output instances of data entities in the context of execution steps of a Business Transaction. 23

2.2.3 Business Function Algorithm Description The means of execution step by step with a certain set of inputs (attributes values) and outputs (values of output attributes). Example VAT calculation, withholding tax calculation, VAT ID format validation, etc. Different calculation methods; verifications required by legislation. Solution steps 1. Identify differentiation of algorithms in relation to defined set of Business Algorithm Categories. 2. Define relationships to data structures (entities and their attributes) and consider influence of different processing on them (for example, for a certain calculation, it is necessary to store an extended structure of inputs in relation to a Localized Unit). 3. Create an optimal level of abstraction and specialization in relation to the difference of algorithms in relation to a certain business algorithm category. It is important to consider the existence of Business Functions in relation to the requirements of Localized Units as well, in addition to the aspects of input and output parameters (attribute instances). For this, we follow similar steps as for the Business Transactions, keeping in mind the difference given by the level of processing (for example, instead of working with data entities we work with attributes, etc.). 2.3 Open Topics in Data and Functional Modelling From a Perspective In the process of data and functional modelling and analysis of localization impact, many changes occur in the individual models, and disorder becomes an issue in the context of the relation of individual artifacts to Localized Units or set of Localized Units (for example, validity of particular changes in European Union). More elaborate diagrams of data modelling become complex and localization layer is not directly identifiable (for example, if there is a question asking which concrete differences exist between localized units L1 and L2 or what are their specifics). When describing functional models, the complexity of defined algorithms executing certain business logic increases, because a lot of differences are created due to divergence in Localized Units. The result is that, in the context of the proposed methodology, it is necessary to include modelling techniques and create supporting and formalization techniques that would enable covering needs resulting from localization differences, and from management and maintenance of these models within the application development lifecycle. Though existing techniques provide some formalization means (especially in the data modelling domain), with increasing system complexity, however, they cease to be comprehensible, without transparently providing differentiation between Localized Units. 24

Conclusion Introduced article summarizes existing state-of-the-art knowledge of localization in application analysis (and partially design). We designate methodological basics in which we propose possible procedures and techniques to apply when developing software solutions requiring functioning in different Localized Units (most commonly a country). We describe steps related to existing application reengineering as well related to their usage or the configuration of applications in a certain country, for which they were not originally intended. In the discussion of data modelling, we have defined fundamental procedures for data entities, associations (relations), and attributes, which must be integrated into the software lifecycle in the case of a localization need. In the context of functional modelling, we derived from existing methods and described fundamental changes that occur during localization of individual functional elements. The designated methodological basics are fundamental for software localization needs; however, they do not cover comprehensively other important software system architectonic aspects, such as more detailed elaboration of the design phase of the lifecycle, influence of translation and language on localization, as well as implementation aspects or the earlier mentioned formalization of supportive techniques and means, the definition of which is our further interest in this area. Key Words Enterprise Software,, ERP, Software Methodology, Analytical Design Patterns, Design Patterns JEL Classification C88, L86, M15, M16 REFERENCES [1] Callaway, E.: Enterprise Resource Planning: Integrating Applications and Business Processes Across the Enterprise. Computer Technology Research Corp., South Carolina, 1999. [2] Čarnický, Š.: Manažérske informačné systémy podnikov. Ekonóm, Bratislava, April 2004. [3] Danko, A.: Globalizácia vývoja ERP aplikácií pre segment malých a stredných podnikov vybrané aspekty. In: AIESA participácia doktorandov na budovaní spoločnosti založenej na vedomostiach: International scientific conference. Bratislava: FHI, 2006. [4] Datsichin, P.: Pluggable business algorithms. [Interné materials.] SAP AG Germany, November 2004. [5] Fowler, M.: Analysis Patterns 2 Work In Progress: Accounting Patterns. [online]. 2000. [cit. 04.02.2009]. Available at: < http://www.martin fowler.com>. 25

[6] Fowler, M.: Analysis patterns: reusable object models. Addison Wesley, Reading, MA, 1997, ISBN 0-201-89542-0. [7] Fry, D. Lommel, A.: The Industry Primer. Second Edition, Industry Standards Association (LISA), 2003. Available at: <http://www.lisa.org>. [8] Gamma, E. et al.: Design Patterns: elements of reusable object-oriented software. Addison Wesley, Reading, MA, 1995. [9] Russev, S. a kol.: Metódy vývoja informačných systémov. Ekonóm, Bratislava, 2002, ISBN 80-225-1542-6. [10] Globalization: meeting local and global requirements. [online]. SAP White Paper, version 1.2, SAP, 2002. Available at: < http://www.sap.com>. [11] Šešera, Ľ. Mičovský, A. Červeň, J.: Architektúra softvérových systémov Analytické dátové vzory. STU, Bratislava, 2000, ISBN 80-227-1358-9. [12] Závodný, P.: Riadenie projektov informačných systémov. Ekonóm, Bratislava, 2003. SUMMARY In this article we describe the fundamentals of software localization, looking at it from the data as well functional aspects. Main focus within the software lifecycle is given to the analysis phase, where we build on the analytical patterns and entity modelling and their fundamental concepts. We describe design and implementation aspects of functional modeling and provide a more broad view on software localization. The main purpose of this article is an introduction to the basics of software localization methodology, describing the different elements of data and functional modelling. It provides initial guidance during design, which is influenced by requirements resulting from legislation of different countries, business practices and other customs. Contact Andrej Danko, Ing. SAP Slovensko s.r.o. Plynárenská 7/A 821 09 Bratislava 2 Tel: +421 (2) 58 25 66 03 Fax: +421 (2) 58 25 63 33 e-mail: andrej (dot) danko (at) sap.com 26