nitzan.levi

    5 Posts

    Overview

    SAP is known as a world leader for vendors of ERP applications and technology platform for large enterprises. However, when it comes to SAP's industry solutions which are tailor made for specific industries, a few people know that some of them are based on the ERP application but some are full blown independent solutions, made for a specific industry/market segment.

    The SAP Banking Platform, also known as Banking Services from SAP, is one of those independent industry solutions providing a comprehensive answer for core banking activities (Deposit management, Loan Management and more).

     SAP embraced SOA as a fundamental design paradigm for the company's future products.  Positioning SAP as the first leading business application vendor seriously implements SOA solutions. The Banking Platform is one of the leading SOA designed solutions that one can find in the enterprise application segment.

    A lot has been said about the SOA paradigm and concepts, but when really starting to implement a true SOA based solution, one is required to deal with some fundamental terms and to understand these terms in a pragmatic manner as well as a conceptual one. Business Object is one of these familiarly dealt with terms a term that is often misunderstood

    In this Blog I aim to take you through the meaning and usage reflections of business object within the SAP Banking platform

    The "Terminology syndrome"

    When one works in an information system development projects, he finds himself having long discussions on different technologies, business aspects and architectural approaches.

    Discussions such as these often raise many questions from various people coming from different areas and backgrounds. The real problems surprisingly arises when dealing with topics where initially there seems to be a clear understanding, because all believe that the term is familiar to them. This is what I shell call the "Terminology syndrome". It seems that only once you dig deep and ask people what their understanding of the term really is; you discover that each person attributes different meanings/understanding to that specific term.

     

    I believe that when talking about Business Object we might come across the "Terminology syndrome". Depending on where you come from, whether you are a SAP consultant, an ABAP developer, a java developer or a DBA, you probably expect different things from the SAP business Object.

    Here are some generic definitions of Business Object I found on the internet:

    "Business objects are objects in an object-oriented computer program that represent the entities in the business domain that the program is designed to support. For example, an order entry program might have business objects to represent each orders, line items, and invoices. ...A business object often encapsulates all of the data and business behavior associated with the entity that it represents"Definition from wikipedia

    "Business Object: A concept from the everyday business terminology and vocabulary of the end-users. Each Object corresponds to a selection of data in the relational database, or a calculation or function using this data. " http://planning.ucsc.edu/IRPS/dwh/BOBGLOSS.HTM

    "business object is a code structure that corresponds directly to a thing in the actual business the software is meant to represent that encapsulates the data that describes, defines, makes up, is contained by, and or is associated with the thing, and encapsulates the business logic related to the thing." http://swcses.eponym.com/blog/_archives/2006/9/19/2341371.html

    As you can see in these 3 examples, the basic definition of a business object is the same but the actual or physical being of the business objects is different. In some cases it is expected to be a programming language object in the memory with all the relevant data and methods related to the business objects, in other cases it is expected to be a unified database structure that contains all the relevant information of a specific BO. These different expectations of what a business object should be might reflect on our basic understanding of what and how we should work with a specific system/software, in our case - the SAP banking application.

    SAP Banking definition of Business Object

    We now understood that a business object is not a trivial/unified definition. Let us now see how business object are defined in SAP banking and how they reflect on the SAP software delivered to customers.

    A business object is a set of entities with common characteristics and common behaviour representing well-defined business semantics. It is described by a structural model, a status and action model (describing the business object's lifecycle), and one or more service interfaces.

    Contrary to general notion of an "object" in an object-oriented sense, the term business object is used here to describe the type and not the instance level. Consequently, the business object Bank Account describes the category of all Bank Accounts and not a single Bank Account instance. SAP banking application design is object-based, not object-oriented. It deals with the concepts of business objects, nodes and instances but does not represent these concepts in a one-to-one correspondence with object-oriented classes and instances.

    The Business Object physical "being"

    If that is the definition, what then is the physical being of a specific business object, if at all? Well, the business object within the banking platform application is not one unified object or table but is:

    • The conceptual model that derived from the actual business processes. These conceptual terms are born during the service modeling phase when designing the business functionality required by the application. (e.g. Bank Account BO when designing the "bank account contract processing" process component and its functionality)
    • The BO Attributes - the data types and information that a BO is built from. Some of these attributes can be used to represent lifecycle of a BO like "StatusCode" that can be filled with values such as "created, "in process", "valid", "closed" etc' as well as classifying attributes that can decide on the nature of the specific BO like "CurrencyCode" that can determined what kind of account it is in terms of currency (EURO, USD, etc).
    • The BO persistence artifacts (Database) - obviously the BO data of a specific instance is at some point persisted into the DB, so there are tables that contains the BO specific data. But again, this structure is not always a 1:1 match to the  BO conceptual model (e.g. if you have Bank Account BO with specific structure in the model it does not mean you will have table called Bank Account with the same DB structure). In SAP this level is never exposed to the customers and it is not allowed to deal directly with the DB level to ensure consistency and supportability of the SAP applications.
    • The BO related service operations - The most important physical artifacts derived from BO's are the enterprise services and operations. The main objective of modeling BO's is the identification and implementation of the right business functionality and to expose it as Enterprise Services meant to be used for composing business processes. So each BO has 1 or more enterprise services that represent business operations one can do on the BO or with the BO (e.g. for Bank Account BO you have the Read Bank Account Current Balance Report service operation that enables you to get the bank account current balance).
    • The BO related backend code - behind each service operation there are several implementation classes starting with the ES proxy classes and other business implementation classes that are used by these service operations. This code is logically related to the BO's since it implements their related functionality, however it is not mapped to a physical 1 BO class in a 1:1 type of relationship as mentioned before. These classes can be used and enhanced according to SAP's standard guidelines.

    Summary

    A business object is a term that might confuse some due to the fact that it brings different thinking on its physical being and availability depending on one's personal background. From a customer implementing SAP banking platform perspective, the BO is important in order to get a better understanding of the way SAP views/clusters the business domain but is not a physical entity that directly interacts with. SAP's view as a standard software provider is to enable customers to implement its functionality using a set of a well defined API's (Enterprise Services, BAPI's, other) without having to get into all the internal structures of the software. According to this view the BO is a tricky one; on the one hand it is an object that is important for the business understanding of the software, on the other hand its physical implementation is too complicated and is related to internal software design. That is why SAP provides the high level information on which BO's were identified as part of specific business process component functionality and its related enterprise services and underlying operations, but does not provide information about the internal structure of each BO

    All the information about BO and Enterprise Services can be found in the Enterprise Service Workplace.

    In my previous WebLog (The story of MDM5.5 The Story of MDM5.5 ) I have introduced you with SAP MDM evolution, and provided an overview of SAP’s MDM5.5 product. Now I want to share with you my thoughts regarding the MDM5.5 current/future integration to the NetWeaver platform.

    When will the MDM5.5 will be integrated to NW ??
    Almost every customer that starts now an MDM implementation project with MDM5.5 asks the questions regarding the NetWeaver integration, and what will be the future consequences for the early adapters of the product. The major issue that troubles customers is the fact that the MDM5.5 server does not run under the NW WebAS but run as standalone C++ server. During this WebLog I will try to explain how I see the integration to NW and why I think that even though the MDM engine does not run under the WebAS the product is NW integrated.

    NW Integration aspects
    When you ask your self whether a certain product is integrated to NW platform you need to tackle the question from different aspects of integration and according to the matching aspects you can evaluate the degree of integration. Let’s try to see what the important aspects when talking about integration to the NW platform are:
     • Running on the same technology – the first aspect that come into mind is whether the product is implemented in the same technology, in our case the question is whether the MDM5.5 is developed in Java or ABAP and runs under the WebAs the second question is whether the product will be migrated in the future. Well the answer to those question is no, the reason for that is that the MDM product is developed in C++ (the engine) and win32 application for both the console and client, this will not be changed because the following   reasons:
         o The MDM5.5 engine is very sophisticated and high performance and implemented a special RAM mechanism. The java and ABAP languages are more limited in the sense of Memory handling and therefore do not meet the requirements for such a product. That is why there is no sense in migrating the MDM5.5 engine to run under the WebAs and hurt one of the most important and crucial capabilities.
         o Both the client and console applications are rich UI that meant to provide advanced capabilities in optimal response time and those types of applications do not fit the Web programming model.

     • Using each other services in a native way – here we need to determine in what way the MDM5.5 interacts with the NW platform and also in what way application running under the WebAs interacts with the MDM5.5 product. From that perspective the MDM5.5 product is well integrated in the following ways:
       o WebAs integration – the importance of integrating into WebAs does not have to be written in Java/J2ee but provide the possibility to interact with the MDM    solution natively from within WebAs applications. For that we have three important ingredients:
          • MDM standard Connector – this connector is compliant to our NW connector framework that is based on JCA (j2ee standard for connectors).the connector enables any application running inside the WebAs to interact natively with MDM capabilities.
          • MDM Java API – full-blown API that exposes every single capability the MDM product provides from java. You can use this API inside the WebAs (using the above connector) or in any other standalone java application.
          • MDM ABAP API - full-blown API that exposes every single capability the MDM product provides from ABAP (running under the WebAs by definition).
       o EP integration – MDM is well integrated into EP because of the fact that EP is running under the WebAs and uses the connector framework mentioned above. What it means is that any portal application (iviews) will be able to use the information and capabilities come with the MDM product. SAP will also provide some out of the box iviews that will be able to present information from the MDM.
       o XI integration – the MDM product is well integrated with XI in terms of splitting the reasonability’s between the two products, XI will be in charge of all the tasks performing complex data transformation, enrichment from other sources and connectivity to source and destination systems.

     • Completion Vs overlapping – this aspect determines whether there is an overlapping relationship between the products or completion, usually when products are not integrated you will see overlapping functionality meaning same functionality is done by both products in different ways, from that perspective the MDM5.5 is well integrated with the NW platform, the product has no overlapping functionality and they complete each other. The MDM provides the Master Management and Catalog management capabilities to the platform and the platform provides the application connectivity (connector framework, portal, XI) capabilities, and the data source connectivity and data transformation capabilities (XI).

     • Development environment – an important aspect of integration is whether you need to have different development environments in order to develop one application that uses both products (runs under the NW platform and uses the MDM5.5). from that perspective the integration is good with room for improvements, it is good because in order to develop the application you only need the NW Development Studio, there you will find all you need (including the MDM API), but if you look at the “MDM environment setup” as part of your development then here you will need to use different environment (the MDM console) for creating and maintaining the data model. Maybe there is room for developing Eclipse Plug-in that will provide the console capabilities (I’m not aware of such plans but …)

     • Runtime environment readiness – an important aspect is how hard do I need to work in order for the runtime environment to be ready, in our case how hard do I need to work in order for the WebAs to be able to host applications using MDM5.5, here the answer is almost nothing, the MDM5.5 will supply the connector you would only need to deploy it (in the standard way) to your WebAs environment and you are ready to go.

     • Installation process – one of the external facing aspects of integration is the installation process, one of the benefits coming with NW is the fact that you have a unified way of installing the different components and they can be standalone but also built on each other, from that perspective the MDM5.5 does not comply to the NetWeaver installation process (currently the MDM5.5 is a standalone installation). I’m not aware of concrete plans for changing that but I’m guessing that in the future the installation will be complied with the NW standard.

    SAP Integration
    All of the above proves that the MDM5.5 is well integrated to NW from technical point of view, indeed it is important but one of the strong points SAP brings to the table is its business experience and its result content, with MDM5.5 we can expect SAP to provide additional value to Master Data Management solution implementation in the following ways:
     • Out of the box SAP Enterprise Portal components that will provide a typical view for Master Data.
     • Business Processes scenarios (via XI) that combines MDM activities.
     • Out of the box MDM data model schemas.
     • More
    Part of the above is already here (like the SAP enterprise Portal iviews, and MDM data model schemas) but you can expect this content offerings to grow and bring extremely important value to the MDM solution.

    Summary
    The MDM5.5 integration to NW is more then just running on the same platform/technology, as we can see the product is well integrated from technical point of view even though it runs on different technology and yes there is always room for more improvement that I’m sure will come in the future. Personally I have two important conclusions regarding MDM5.5 integration to NW and SAP:
     • The first important conclusion I have in the technical aspect is that I can start implementing MDM solutions with MDM5.5 today without being worried that NW integration issues will affect it in the future. The reason I’m drawing that conclusion is that the core of MDM5.5 is already NW integrated and the future changes that might come (development environment, installation process, etc) will not affect the core functionality of my solution.
     • The second important conclusion is that I can expect to see more benefits coming from SAP in the business content area of MDM, and that gives me a tremendous added value for the future.

    Nitzan Levi

    The Story of MDM5.5

    Posted by Nitzan Levi Jun 20, 2005

    During the past couple of month I was introduced to the MDM world and our product now called MDM5.5 also known as MDME and I wanted to share with you my insights regarding this amazing tool and its capabilities.

    SAP – MDM background
    Before we are getting into the MDM world and MDM5.5 details it is very important to give some background on the MDM product evolution in SAP. Anybody that is a little bit familiar with SAP products and NetWeaver platform knows that the MDM product was available for the last few years and its last version was MDM 3.0 this product was ABAP based tool with very strong capabilities in large scale data integration and consolidation between SAP systems, the problem with this tool was that it was too complicated for implementation and less strong in the client side. In order to make it better SAP had to decide whether to invest more development efforts or buy some other product that will be able to provide the missing capabilities, during the quest for this tool SAP found this Israeli company called A2I and their product called xCat. Even though the xCat product was intended for product catalog management SAP identified the grate potential in it both from conceptual and technical point of view and decided to buy it and make it SAP’s MDM product. At first this product was called MDME (MDM Extension) but now it was announced as the MDM official tool by SAP. The MDM5.5 tools is a very sophisticated tool from one hand providing great Data Modeling , data consolidation, fast data extraction , and search capabilities, and from the other hand it is very simple for installation and implementation (both from infrastructure point of view and end user experience). So now SAP has a very strong offering in the MDM world:
      • Large experience in MDM scenario’s as it was captured during the years in the “old” MDM development team.
      • State of the art technology which enables you to do complex things with relatively small effort.
    In order to explain how product catalog tool becomes MDM tool we need to explain what are MDM and PCM.

    PCM – Product Catalog Management
    A PCM product helps a product oriented company (can be in the retail or manufacturing) manage the different aspects of information regarding the product. We are not always aware of it but it can be quite complex and a lot of information to handle. The reason for that is that a product can be built from several parts, can come in different sizes, colors, and can be connected to other complimentary products. every product oriented company has to have its product catalog in order to use it both internally (for manufacturing, purchasing, etc) and externally (customers, suppliers, etc). In most companies the product information comes from different places in the organization (manufacturing, purchasing, operations, etc) derived from that it is stored in different IT systems. So PCM product needs to provide the following capabilities:
      • Extract product information from different IT systems
      • Consolidate information and convert different terminology of the same product (remember it comes from different places in the organization)
      • Provide sophisticated ways of organizing the information depending on the target audience using this information.
      • Provide ways for fast and intuitive search.
      • Provide different ways of displaying the catalog (by application, printing, on line, etc )


    MDM – Master Data Management
    Here we need to answer what is Master Data, well if I will try to define it in a simple way I can say that Master Data is descriptive data regarding specific entity. The Master Data is fairly Static and it is not contains transactional information. For example let’s take the Supplier entity and see what information we save on it and what is the type of each one:

    DataType
    Supplier NameMaster Data
    Supplier AddressMaster Data
    Supplier list of productsMaster Data
    Number of invoicesTransactional
    Next shipment dateTransactional

    From the above table you can see that the transactional data is business process specific, for example the “Number of invoices” related to the company’s accounting business process but the “Next shipment date” is more related to the operational side, in most cases those business processes will be done by different IT systems/ modules, but both of them needs to have the same Master Data. Unfortunately this is not the case in the real world, and each IT system has its own way of saving and maintaining this Master Data. That leads to several problems in the organization that causes lose of Money like:
      • Duplicate maintenance efforts – maintaining master data can be quite complex and time consuming operation.
      • Unable to cross information like the same client owes money in one company division but we pay him in another division. If we known that it is the same client we can save the money we are paying him.
      • More
    So Master Data Management systems came to solve those issues, by providing tools for:
      • Extracting master data from different IT systems
      • Consolidate master data coming from different sources meaning:
       &nbspo Identifying similar entities
       &nbspo Converting data from one terminology to another
       &nbspo Providing a way of building cross organization terminology without enforcing change to the different IT systems.
      • Central Management crosses IT systems.
      • Master Data Provisioning from and to the different IT systems in the organization.
      • More
    Now you can see that the PCM is just a private case of MDM with some extensions like printing catalogs or image management. That is the same conclusion SAP drawn when it saw the xCat product now integrated into NetWeaver and called MDM5.5.



    MDM5.5 Overview
    So as I mentioned before the MDM5.5 product can handle both PCM and MDM scenarios, I want to talk about the MDM scenario and leave the PCM to some other time. As mentioned above in order to mange Master Data I need to have a tool that will enable me to:
      • Define a generic/flexible data model
      • Import master data from different sources
      • Manage my Master Data cross organization (find duplicates , find similarities ,define transformation rules, etc)
      • Maintain the Master Data in the most efficient way through out the company.
      • Support personalized access to Master Data according to end user profile (language, search behavior, data interest, etc )
      • Synchronize the Master Data with different systems holding equivalent information.
      • Provide scalable solution that can hold large scale of Master Data.
      • Provide fast access to the data (especially when it comes to large number of records)
      • Provide access to the Master Data information from applications (new and old)
    The MDM5.5 product enables all the above and more together with the NetWeaver platform you are getting a robust MDM solution that can solve almost any Master Data scenario you have in your company. I will not go into the details (maybe in future weblogs) but just want to introduce you with the MDM5.5 building blocks and their part in the show. In the picture below we can see the MDM5.5 architecture and main components:

    image

    After my previous explanation regarding the MDM5.5 background we can see that the Image Manager and the Plug Ins (QuarkXPress and Adobe InDesign) are part of the PCM scenario’s supported by this tool, the Image Manager is for handling Images usually kept in products context and the Plug Ins are meant for publishing the product catalog in different ways. I will concentrate on the MDM part of the product:

    Management Consol
    The console is the tool intended for two major roles:
      • MDM administrator – the console enables all the administrative tasks can be done via the MDM5.5 (connectivity, accessibility, security, etc)
      • MDM modeler - creation and maintenance of the object/data model as defined according to business needs. This tool enables you to model your Master Data in a way that it will reflect your original data model and business constraints (I have to say that I’ve seen some complex data models that was smoothly modeled into the product in no time!).


    Import Manager
    The Import Manger is responsible for importing data from several data-sources (can be relation DB, can be excel-sheet) in order to define and population of the data model. With this tool you will be able to define the rules for importing data into your model according to source structure. Here are the definitions will be done via Import Manager:
      • Aggregation of data from electronically format (the source)
      • Data Transformation rules
      • Data Rationalization rules
      • Data Normalization rules
      • Data Cleansing rules
    All of those rules will be implemented during the data import (and all of the above is without coding!!)


    Syndication Manager
    The Syndication Manager is the component that knows how to exchange data with other systems, meaning this tool will be the one that will handle the synchronization between the MDM storage and the source systems. The syndication manager will not do it alone but it will use the XI in order to provide a robust way for interacting with any system the company has in its landscape and also add some more information (if needed) and sophisticated transformation rules needed during the process.


    Content Manager
    The content manager is the tool for the end user needs to maintain and work with Master Data in the organization. The content manager also called “the client” is a very sophisticate tool that enables the end user to do the followings:
      • Fetch data in the most intuitive way, this can be different from one end user to another even though they are using the same data model.
      • To manage the master date stored in the MDM (add, change, remove), this can be done with workflows.
    The content manager supports multi-language both for the master data and the client GUI itself in one of the simplest ways I have ever seen. and it is dynamically build according to data model defined by the MDM modeler.


    MDM Server
    The MDM5.5 server is the engine that enables us to do almost anything in the product, as you can see in the diagram all the components above are just client applications communication with the server (via TCP/IP proprietary protocol), most of the operations are server side.


    MDM API
    The MDM5.5 server exposes API both for java and Microsoft applications (.Net and previous) that enables your applications to use the data and functionality provided by it. Due to the fact that most of the MDM5.5 functionality is done in the server, every thing that you can do from one of the clients above you can do from your applications via the API. API for ABAP is being developed as we speak and will be available in the near future.


    I hope this weblog clear some questions and fuzziness regarding the MDM world and SAP NetWeaver MDM solution, and most important I hope that I’ve managed to reflect my enthusiasm from this tool. I’m recommending to anybody how is interested in the MDM world or just a technology “frik” to download the tool and play with it and I’m sure you will like as much as I did


     

    “I can develop this utility it’s very simple…..”



    Didn’t you here or said this sentence (or something similar) at list 10 times on different development projects? Well I did, as a developer, Team leader and development manager for several j2ee projects I often heard (or said) this from developers that wanted to develop some new utility or tool that will make our life easier. So what’s wrong with that? Well from my experience in development a lot of this “simple” tools and utilities ands with:
      • Longer time effort then planned.
      • Missing functionality that cannot be developed (lack of time, knowledge, etc)
      • Unstable tool with lots of Bugs.
      • A lot of maintenance (that after awhile nobody knows how to do it).
      • Discovery of a standard product that can be downloaded or bought that would be much cheaper and stable.

     

    So what should we do then, my suggestion is that you try to answer the following questions
    before getting into development:

    • Do I really need this? - Find out if it’s really needed a lot of times we don’t really need this tool/utility because we can get the functionality from different sources. So I suggest that before you go into development even if it sound logical and simple perform brain storming session with a few people (try to build a heterogeneous group) in order to asses the need for this tool/utility.
    • Is it really that simple? – try to challenge your self, is it really that simple or maybe you forgot something like monitoring, rollback, performance, dependencies, openness to changes etc. it’s most problematic when talking about developing engines or other centric tools. a lot of times we focus on the immediate need and we don’t see the bigger picture, monitoring is a good example for it, we invest a lot on monitoring tools and capabilities but then we have this home made engines/tools/mechanisms that our application is build on and we have no possibility to monitor it’s behavior just because we forgot to develop the monitoring capabilities.
    • Can’t I find an open source or an already made product for this? – Before you go and start developing something try to find some one else that done it before you. Today we have quite a lot of Open Source projects that developing tools and utilities that every body needs. If you can’t find some free product maybe it’s better to buy. For developers it is always seems waste of money but to the organization many times it is cheaper to buy a product (that comes with support and experience) then home made development.
    • Do I have the skills to develop it? – a very important question that unfortunately is not being asked is do I really have the right skills to develop this tool ? And by saying that I’m not talking about the programming or technical skills but the organizational skills. If my team need to develop a project to an insurance company for 1 year would it be smart to develop transaction engine or security mechanism? Am I (my team) skilled to design this tool?
    • How much time would it take to develop? – Before you start ask your self how much time it would take to develop the tool until it would be complete and stable. Here we should take into account all the satellite aspect like monitoring, performance, configurability, integration to other products/components, etc. by analyzing the situation you will always see that the time the developer told you it would take and the time you will get after the analyzing has a huge gap.(the developer is always optimistic)
    • How much time and effort would I need in order to maintain this product? – When you analyzing the situation take into account the time and effort you will need in order to maintain the tool. When developing a tool from scratch you always discover that you forgot this and that, and there are always new things that the users need that you did not thing about etc. so the development time is only part of the time and effort you need for this tool. When you are buying an already made product you probably save this problems (assuming that the product is not new and there is an industry experience working with it).
    • Who will use it and what about support? – the last but not least aspect you need to think about is the future support for this tool/utility, your tool that you built is being used in production for a few years somebody would have to support it in case of problems or new features that would be needed. Will you have the ability to support it in the long run after the solution will be productive?

    Summary
    So I hope that my message is clear, I’m not against developing new and interesting things but I do think that it is important for us to know what is our scope and capabilities before we get into new adventures. If we are developing solution for a customer we have to remember:
      • Usually our time table is very limited.
      • We don’t have the right skills and resources.
      • Somebody must have done it before us – find it !!!
    Hope that helps - enjoy

    Overview

    Wouldn't you like to have a tool that helps you with verifying the code you or your colleagues are writing, helps you in finding code faults, helps you in knowing the code that is being developed near you (in other teams/developers), helps you learn new API's and development techniques, helps your organization with forcing a well defined development guideline, etc….? Well there are some technical tools for achieving some of the above mentioned goals but there's one famous process for that that is called Code Review. The most interesting thing in Code Review is that everybody knows it (or at least heard about it) but too many developers don't do it. During this weblog I will try to describe what a Code Review is and its importance for any development team (from the smallest to the biggest), and any programming language, and how easy it is to do it.

    What is code review?

    Code review is part of the Quality Assurance process regarding programming. This process is a consistent task that is being made in parallel to the development process. During the code review we are going over the code that is being developed in order to make sure that the code is well written according to our industry standards. The code review is being done by other developer/s (or other role with language and coding standards experience) and not by the one that wrote the code. It is recommended that in the code review we will have a number of participants with different programming skills. This process is important both to small and big development teams/organizations and it saves time and effort to the organization in several ways:
    • Reducing bugs – by reviewing the code we can identify bugs before they are shipped to production (or other testing environments). During the code review it is very easy to identify mistakes the developer missed.
    • Improving the code performance – usually in code review we have strong and experienced developers that can easily identify bad practices, inefficient code and make suggestions for improving the code.
    • Knowledge Transfer - share knowledge between the developers within the same/other development groups. By reviewing each other's code the developers can learn from each other in the sense of what to do and what not to do.
    • Better maintenance
     &nbspo By reviewing the code, the developers know each other's code and can maintain this code if needed (in case of personnel changes).
     &nbspo During the code review you can make sure that the developers are writing the code according to the organization/industry standards that will make sure that the code is easier to maintain.

    What should we review during a code review?

    During a code review we will check the following:

    Coding according to the organization's coding conventions – every development team/organization should have its coding conventions; the code review process is the process that helps us make sure that our developers are applying these conventions. Here some examples:
    • Does the source file start with an appropriate header and copyright information?
    • Are variable declarations properly commented?
    • Are all functions, methods and classes documented?
    • Are function parameters used for input or output clearly identified as such?
    • Etc
    Error Handling – error handling is a very important part of coding. A lot of bugs are made because of bad error handling. Here some examples:
    • Are errors properly handled each time a function returns?
    • Are resources and memory released in all error paths?
    • Are all thrown exceptions handled properly?
    • Is the function caller notified when an error is detected?
    Resources handling – resources handling is a major problem with coding, we often see programmers forgetting to release resources or missuse them in a way that can damage the code performance or, more dangerously, the all system stability. These kinds of errors can affect other developer's code as well. Here some examples:
    • Is allocated memory freed? Even in Java we have to make sure that the code is written in the proper way in order for the Garbage Collector to handle this memory as it should.
    • Are all objects (Database connections, Sockets, Files, etc.) freed even when an error occurs?
    • Is the same object released more than once?
    • Reuse of resources (Database connections, large data objects)
    • Creation of unnecessary objects (like in loops).
    Thread Safety – in our code review we have to make sure that the code is safe from threading perspective. Here some examples:
    • Are all global variables thread-safe?
    • Are objects accessed by multiple threads thread-safe?
    • Are locks released in the same order they are obtained?
    • Is there any possible deadlock or lock contention?
    • Can we use threads (for example on J2ee - EJB)?
    • Are we locking in the right scope (can affect performance)?
    Control structure – we need to make sure that the control structure is being done properly. Here some examples:
    • Are loop-ending conditions accurate?
    • Is the code free of unintended infinite loops?
    • Are if statements defined accurately?
    Performance – we have to make sure that the code is written in the optimized way and will have the best performance we can achieve. Its is very good practice to first code from the functional perspective , and then review and try to see how can we implement the same functionality with better performance and efficiency. Here some examples:
    • Do recursive functions run within a reasonable amount of stack space?
    • Does the code have an impact on size, speed, or memory use?
    • Are you using blocking system calls when performance is involved?
    • Is the code doing busy waits instead of using synchronization mechanisms or timer events?
    • Was this optimization really needed?
    And more - I'm sure you can think of additional topics that need to be checked during the code review.

    How should we do it?

    There are a number of formats that I've encountered during my development time to do a code review. Here's one way to do it that I found very useful:
    • Reserve a fixed day and time for making a code review session, the frequency should be determined by the project size and time table.
    • Appoint a code review officer that will manage those sessions.
    • For each session invite:
     &nbspo The developer whose code you are going to review.
     &nbspo Team leader/senior developer.
     &nbspo A few developers both from the same and other teams.
    • The group should not be too big (not more then 10 people).
    • Appoint one of the participants to document the review.
    • Create a code review session report document – this document will be filled on each code review session.
    • During the code review the developer will describe its code logic.
    • During the review each one of the participants can ask questions and suggest alternative code if needed.
    • During the review every participant has the same rights (even if he's new to the company or in work).
    • Every suggestion should be discussed during the review in order to decide if the change should be made.
    • Every decision for change will be documented in order to make sure that it won't be forgotten.
    • After the code review the developer can get the document with all the change decisions and start work on that. Its team leader should make sure that all the changes are made.
    • It's good to send this code review session report to all the developers in the organization so they can learn from it.

    Summary

    The code review session is a very simple process that contributes to the organization in many ways. Though it's simple I see too many organizations that do not apply it. In order to make sure that our code review process will succeed we have to remember that:
    • It's important to make sure that every person that writes code will be reviewed.
    • It's important that at least more then 40% of the code will be reviewed (it's not realistic that 100% of the code will be reviewed).
    • It's important that every person that writes code will participate in other's code reviews (as much as he can). That way we make sure that our developers will learn from each other.
    • It's important that this process will be sponsored by the management.
    • It's important to include this process in our work plans (this process takes time and resources that have to be taken into account).
    • It's important to share each session's results with the whole group (spread the knowledge).

    I hope that during this weblog I've managed to explain how important this process is, and even though it looks complex to organize it, I can assure you from my rich experience that it's quite simple and very profitable to the organization as a whole and for each person in it.
    Enjoy

    Filter Blog

    By date: