What Is a Business Object Model?

Business Modeling is a software model that describes the objects and elements involved in enterprise management and business, as well as their attributes, behaviors, and relationships. Business modeling emphasizes a systematic way to understand, design, and structure enterprise information system.

Business modeling

Business Modeling is based on

Business Modeling (Business Modeling) is a collection of modeling methods, the purpose is to model the business. This work may include

Master Brooks said that over the past three decades, various application programs (Application Programs AP) have been modified many times and have become beyond recognition, like a group of monsters, difficult to tame.

Master Rogerson also said that The application is a rock in the river of change.

For many companies, the desire to have an information system that integrates all departments of the company seems to have become a luxury. There will be more or less application systems in the enterprise to assist the automated operation of the enterprise. When the corporate information executives hope to integrate the information system and cooperate with the development of the enterprise, they are disappointed. Most applications lack a unified interface and are difficult to integrate.

We also found this problem in the banks where we develop projects. The systems of different departments cannot be interconnected.

Understand the structure and mechanisms of the target organization (the organization in which the system will be deployed).

Understand current issues in the target organization and determine the potential for improvement.

Ensure that customers, end users, and developers agree on the target organization.

Depending on the environment and needs, business modeling efforts may be of varying sizes. Listed below are six such scenarios.

Project stakeholders

Business modeling is

We discussed a lot in the last post

business

Who is "God" in Business Modeling

We say that the customer is God, because the importance of the customer, the customer has a decisive position. But in software development, who has the right to decide? Is it the funder, the project manager, or the programmer? Unclear responsibilities are one of the main reasons for failure of business modeling. We can easily see that customers condense their requirements in a few words and throw them to developers, or developers develop programs according to their wishes. Could it be said that there is really a "heart and soul" between the customer and the developer, and there is no need to communicate at all. I have mentioned the rights and obligations of project stakeholders and developers in the previous article, and I think it is necessary to emphasize again here. Scott W. Ambler said: it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them. During my first development process, I met an interesting stakeholder, and he was in his The requirements analysis wrote: "In short, to achieve the kind of function that can be thought of." I think this stakeholder has very ambitious ambitions for our computer industry. But I had to tell him politely that it was not realistic. Everyone may find it funny, but in my career dealing with customers myself, such customers are not a few. This is the reality, what do you do? After a smile, did you leave it alone? I think most people will do this. Because his request is ridiculous. But have you taken the time to understand what he meant by his absurd words? I think that software developers have the obligation to educate stakeholders, and you need to guide your stakeholders and let them speak their minds. After seeing this sentence of this stakeholder, I took some time to understand. Actually, the thing is very simple, he just wants a function that can customize the report template. After the project was over, I and the stakeholder were fortunate to cooperate again. At this time, he has become an outstanding client-side project leader. What does this example illustrate? Stakeholders are often domain experts and have a deep understanding of their work. However, due to their lack of understanding of software development, stakeholders often cannot express clearly or even express their needs. At this time, it's time to reflect your skills. Remember to treat your customers like God.

Business modeling patience is paramount

If you understand who "God" is, then you have to be patient with God. People who study science and engineering are generally better in logical thinking, but for stakeholders, this is not necessarily the case. I met a stakeholder involved in archival work. When he understood the needs, he talked about it and was vague. The method that was negated only a minute ago was proposed again the next minute. I think my temper should be good, but in the end it was almost cyanotic. Fortunately, I finally survived. I think that after experiencing this, my patience index will improve a lot.

I admire the patience of a colleague. In a website project, he is responsible for system analysis. He spent three full days living with the head of the website project. After a systematic analysis, he was in a good spirit, but the person in charge was almost dead. Of course, this is just a joke, not to encourage everyone to work hard. The combination of work and rest is still very important. The body is the capital of revolution. But this tells us that without patience, demand is difficult to succeed. For example, at a business modeling discussion, although you specified that this meeting discussed high-level requirements, the participants always debated some small things about sesame and mung beans from time to time. what would you do? I believe this situation is very common.

In the end, patience will still be reflected in communication. Only with patient communication can you lift the veil of demand. Human behavior is always guided by thought. If you can't solve the stakes of the stakeholders, you will not understand what he really needs.

The performance of one of my project stakeholders is very strange, she always kept saying one thing: "She wants to realize automatic report generation." Her requirements seemed to be incapable of coming out of this scope, but I Almost nothing else could be heard from her. At this time, I decided to give up. I think there may be no more information from her. But after I learned that report processing in her job took up a lot of her time, I changed my mind. After I spent some time helping her clarify the idea of report processing, she also helped me a lot in other aspects.

Business modeling engagement is important

An important practice of the XP method is to promote "on-site customers". In other words, customers should be with developers at all times to provide information and make decisions. And this client must also be a domain expert and able to make decisions.

Such on-site customers believe that most domestic software organizations can't. But we must work hard in this regard. I think there are two types of on-site customers: one is the project stakeholders, and the other is an industry expert. In fact, many software companies will be equipped with some management consultants, these people are industry experts. Statistics show that the ratio of consultants and developers in Guangdong software companies has reached 1: 1. I think this is a good thing. Project stakeholders often have a deep understanding of the transactional part of their work, but it is difficult to raise it to a theoretical level. At this time, some industry experts are needed to help. Involving industry experts and projects

The common discussion can also inspire the project stakeholders and think of aspects that he had never thought of. This is the development of "potential requirements". On the other hand, participation also means that the project stakeholders need to devote themselves to the business modeling process and be able to motivate them. So, too complex processes can hinder stakeholder participation. Therefore, it is necessary to use some simple artifacts that can be accepted by customers for business modeling. I said the "protagonists" and "use cases" discussed earlier. That's the theory. It's for developers. It gives developers a sense of what's going on. You show this to the stakeholders, can they understand? When they understand the mechanism, I'm afraid the daylily is cold. User stories, features, and CRC cards are all very good artifacts, which are both simple and meet the needs. Knowledge point: Both the material and characteristics express a simple requirement of the user, which can be completed in a short time. The material is the artifact in the XP method, and the characteristic is the artifact in the FDD method. CRC is an abbreviation of class, responsibility, and collator. It is a card divided into three parts, which respectively mark the class name, the responsibility of the class, and the cooperative relationship between the classes. It is very close to customers, and can even complete the card filling in the process of making games, which can bring strong customer participation.

Business modeling embraces change

I think this will be accused by the developers. After all, changing requirements is one of the most annoying things for developers. Yes, I hate it. But, as we often say, "Crying doesn't solve the problem", do you hate it? Reject the customer's request for change and ask the customer to sign the requirements specification. These practices can only be counterproductive. There is no positive, positive meaning.

Necessary requirements change management is important. Because endless and uncontrolled changes will inevitably cause a great waste of resources. On the other hand, the acceptance criterion for requirements changes should be "reasonable", and requirements changes require our development work to be carried out iteratively, including the requirements, design, and implementation stages. This will minimize the risk of change. We will discuss this further when we discuss specific requirements modeling.

The next level of embracing change is to anticipate change in advance. Develop a list of possible changes to record possible changes. The simplest example is that after an enterprise develops an invoicing system, it hopes to develop an accounting system to connect to it. If you can leave a foreshadowing in advance, I believe it can save a lot of effort. Another way to predict change is through usage patterns. But keep in mind that the use of patterns should not be overdone. These are digressions, and if I have the opportunity, I will focus on this aspect in other articles. Practice of business modeling (Practice)

Business Modeling Conference

Meetings are the most important means of business modeling. Although conferences always bear some infamy in China, as long as they are well organized, they are a fairly effective means of communication. A modeling conference is a large-scale conference, in other words, all relevant people should attend the conference. Because in the business modeling period, the main purpose is to establish high-level requirements for the system, which requires the joint participation of many project stakeholders to ensure the breadth of requirements. So, the scale of the modeling conference is quite large. Funders, senior managers, managers, direct users, developers, and people from all sides should participate in or send representatives to modeling meetings.

If everyone has experience in participating in large-scale meetings, you know that the larger the meeting, the lower the efficiency of decision-making. this is normal. Because when you are alone, you do not need to communicate, and the decision-making efficiency is the highest. When two people wait, they need time to communicate to make a decision. Waiting for three people will take longer to communicate and reach an agreement. If the number reaches four, five or even one or twenty, most of the time will be spent on communication. What's more, there are still different ideas and interests between people. So, in order to ensure the efficiency and effectiveness of the meeting, certain rules should be followed:

Be prepared: If you have a meeting and the participants don't even know what the content is, what will you do? You must first spend a lot of time explaining the purpose of your meeting, isn't it? The meeting subject, agenda, and meeting notice should be sent to the participants in advance, so that they can make preparations so that they can quickly get to the topic when the meeting starts.

Invite as many people as possible: I've said that if a modeling conference cannot hear the widest range of opinions, it is not a successful conference. But in reality, this is often difficult to achieve. Because the target organization as a client is often "tugged", it is simply impossible to achieve all of them without fully understanding the importance of the meeting. Objectively, there will be business trips, vacations, important events and other reasons that cannot do this. Here, on the one hand, you need to clarify the interests of the decision makers of the target organization and let them pay attention. On the other hand, you also need to actively invite project stakeholders to participate. Because it's impossible to invite everyone, as many as you can.

· Separating the level of participants: I like the conference room with an inner circle and an outer circle. Because I can't invite everyone, I must first ensure that all the core personnel can be present and sit in the inner circle, and then be the secondary person in the outer circle. Core people are the kind of people who are closely related to your project. For example, in the financial system, the financial director is the core person. It is necessary to ensure that all core personnel are present. As for the secondary personnel, the more complete the better.

Beginning from the bottom: Chinese people have a bad habit. When the boss says one, he never says two. So let the bottom speak first, then turn to the middle, and then to the upper. Developers don't speak, they either listen or lead everyone to speak. If we let the leaders talk first, then the people at the bottom will not have to say anything.

List all the opinions of all stakeholders: First, let everyone speak freely about the new system, and then list all the opinions on the whiteboard. There may be some ideas here that would be ridiculous, but it doesn't matter, although it is written. This is a brainstorming process and it is easy to generate new ideas. The main job of the hosted developer is to guide and encourage everyone to say more ideas and record them. Here we digress a little bit, and some people say that the Chinese are mostly reluctant to express their opinions at the conference. I don't think you need to worry too much about this kind of modeling conference. Why, because the project stakeholders do not need to take any responsibility for their speeches, say, Bai said, who said not.

· Categorize your views: Presumably your project stakeholders are a little tired, your creativity is almost the same, and your whiteboard is estimated to be full. But if you look at the views on the whiteboard, many of them are duplicates, and many of them are similar. So you need to categorize these ideas with logical ideas. This work can also be guided by you.

Prioritize: It's also important to prioritize ideas. It can help you identify significant risks and provide guidance when developing iteration plans. Again, this work should be determined by the project stakeholders.

· Investigate the main business logic: What is the main business logic? Including the company's main business processes, main business rules, major algorithms. These are materials that need to be very clear from the beginning and need to be understood at the modeling conference. Of course, you cannot say to your project stakeholders, "This, next, let's talk about the main business logic." The stakeholders below must be scratching their heads. You should still guide your stakeholders and capture the information you need from their words.

Pay attention to meeting time: people are not machines and are tired. So controlling the length of the meeting is critical. Generally, such meetings have four to five hours. According to statistics, meetings within two hours will not cause people to feel tired. So the meeting should be divided into small sections. In addition, you can also decide how many people will participate in each segment based on the progress of the meeting. Because, the further back the conference is, the less important some participants are.

Avoid details: The main goal of modeling meetings is to establish high-level requirements. If you spend too much time discussing trivial matters, it will waste everyone's time. At this time, it is not meaningful to investigate the details of the requirements. Because you don't know a lot of things, you need to go deeper. The details at this time will not help you much.

· Avoiding technology: When I was in a modeling meeting, I met a stakeholder responsible for technology. He always asked the technical architecture of the system and promoted his design concepts. I have to reiterate several times, "We will find time for technical issues alone." I think that the technical staff should have a better idea, and I hope to show it. This is understandable. But this time is not the time to discuss technology, and the needs have not been clarified. Isn't the discussion of technology implementation upside down?

· Keep a record: As the saying goes, good memory is worse than bad writing. So it is very important to keep a record at the meeting. Because the cost of such a meeting is quite high, your project stakeholders cannot not work every day, and if you are with the meeting, even if they are willing, their boss will not. So to make full use of the results of the meeting, a good shorthand is absolutely necessary. In addition, according to research, if you use a tape recorder, participants will be reluctant to speak, so do not use a tape recorder.

Business Modeling Test

It may seem strange to mention testing at the beginning of a requirement. For any project, there will always be a standard to assess its success. The test here refers to an "executive goal" that evaluates the success of the software project.

This goal will be the final conditions to be met for software development and the criteria for the success of the software. Many enterprises do not have a clear goal in the information construction. So when asked this question, his answer is often that my goal is to build an enterprise's ERP system, build an enterprise's information platform, and other empty words. How is such software developed? There is no standard for ending. Should the cost run out or the decision maker stop? Goals should have a quantifiable standard. For example, the purpose of developing a logistics system is to shorten the product turnover cycle and reduce inventory; the development of a supply chain system is to strengthen contact with suppliers and reduce inventory. These specific business-related indicators can be measured through refinement and multiple sub-indicators, so they can be achieved.

When we call this goal a test, we remind developers that meeting this goal is the ultimate test. No matter how good your software is, it is not what the stakeholders want, what use is it? This is a very simple truth, but in practice, the stakeholders and developers often cannot see this because of some specific factors. In fact, we also talked about this goal in the previous article. At that time, we called it vision and scope. It's essentially the same. This "executable goal" can be measured using a number of factors:

Business Modeling Business Entities

Business entities are some of the key categories in an enterprise. Customers, suppliers, employees, orders, and vouchers can be cited as examples of such business entities. Business entities often become a very critical factor, because in the system, the behavior of the role operation business entity is often assigned to the business entity, for example, "calculate the price according to the order" will be completed by the cooperation of multiple business entities. Therefore, the design of the business entity will greatly affect the system.

The main work of business entity design includes identifying business entities and determining the attributes and behaviors of business entities.

To determine a business entity, you must first identify the role and identify the business entity from the role's behavior. Roles require us to discuss the target organization. In my personal experience, finding business roles is generally simpler, but keep in mind that one person may have several business roles, which is often the case. From the behavior of the business role, we can find out what the business role handles. These are the business entities we need. Whether a business entity is a separate business entity or a property of a business entity is worth studying. A thing that is supposed to be an attribute is judged to be a business entity but it will bring some overhead, but a business entity that should be listed separately but just judged as an attribute of another business entity may bring disastrous consequences The biggest possibility is that the system is difficult to expand.

In a human resource management system, the employee class may be a very important business entity, and it may have many attributes. In other systems, such as invoicing, the employee class only plays a role of records and rights management. For another example, in some enterprises' automated processing systems, customers may only be attributes of other entities, and customer-centric design has become popular in the 21st century. This design has its fatal flaws. To determine the attributes and behavior of a business entity, it is mainly to determine what each class (business entity) is to do, and attributes are to be able to better describe the class and the things that the class is to do. Using CRC cards is a good way. CRC is the abbreviation of "class", "responsibility" and "collaborator". These materials are often presented on a card. Class name Responsibility 1 Responsibility 1 Responsibility 1 Responsibility 2 Responsibility 2 Responsibility 2 ... By making such a CRC card, it is easier to find out the behavior (responsibility) and attributes (supply) of each business entity. You might ask, why not just figure out attributes and behaviors, but do it all. This issue is something we have been emphasizing. In the modeling phase, we are facing stakeholders who may not understand computer technology at all, so adopting an easy-to-accept method can ensure the completeness and accuracy of the requirements.

Business Modeling Preparation Plan

There are two extreme misconceptions about planning in software development. In some software organizations, there are generally no plans or general, useless plans. Some developers believe that "doing a plan is not as good as doing something practical." For the project manager, there is no way to deal with this situation, or the released plan developer is insulted, making the plan a dead letter. The execution of the project is extremely random, and things that deviate from time to time often occur.

In other organizations, planning is considered the top priority, and it takes a lot of time and manpower to make a plan that can be described as trivial and incomplete. Project managers who write such plans are also considered senior talents. The developer sighed, "It's better to write a program than to write a document." However, when it was executed, the original precise plan was often full of loopholes, and the progress of the project was delayed. All of us know the plain statement: In software development, it takes 90% of the time to complete 90% of the project, and then 90% of the time to complete the remaining 10% of the project. why? The plan is unscientific.

In management, planning, also called planning, is defined as "the process of determining the goals for an organization and the strategies and means, steps, and procedures for achieving them." For example, I want to push a box down to a place. This place is my purpose. In order to get there, do I have to estimate what route to push and how fast. Then I started to push and compare it with the original plan from time to time, without the need to adjust the route and speed. This estimate is the plan.

The goal of the plan is not to eliminate mistakes, but to make all mistakes into a small and carefully planned mistake. After researching the four design methods, I finally gave up three, but it was only three small mistakes. However, rewriting the program three times because I did not do a good design may cause three big mistakes.

But why are there the two extremes mentioned above? The first situation is actually the earliest form of the software industry. There is no plan, the allocation of resources is chaotic, and the software development process is in a chaotic, disorderly, and spontaneous state. The success of the project depends on luck and the personal capabilities of the project members. The second case is actually an advanced form. The most typical representative is the waterfall model we mentioned before. So why is this thoughtful plan prone to failure? Quite simply, you think you think carefully, but in fact it is not necessarily. I've seen timetables advertised in their own well-thought-out plans that are 7 days a week. It seems he didn't plan to give developers a break from the beginning. The plan is an estimate of the future. I am afraid no one will be able to tell exactly what will happen after 6 months. Before September 11, how many people could have expected such a big thing that day? So why do you figure out what happened in half a year, or even a year later? Also, do you really know your developers so well that you have the confidence to make plans for them?

Some people say that the plan is not changing fast. This sentence is true, it reminds us that it is not possible to have no plan, nor is it to have an executable plan. The plan is not to show off, but to be implemented. When we make a plan, there can be no gorgeous words, beautiful ideas. But we can't live without some elements:

What (WHAT): List in order the work required to achieve the goal;

When (WHEN): the time required to complete the work;

How well done (HOW-WELL): What is the measure of the work to be done?

Resources (RESOURCES): personnel / funds required to complete the work;

Who (WHO): Who is responsible for completing the task.

But we still can't escape the problem of deviation from reality and plan. Although we are not very sure about what is expected one year later, we are not quite sure what developers are thinking. But if you think about it two weeks later, you should still be able to guess it. This leads to the concept of iteration. A project consists of several or even dozens of iteration cycles, and each iteration cycle is relatively easy to estimate and make a plan. This is the idea of iteration and a big leap in software engineering technology.

Business Modeling Training

It's hard to imagine how a project would proceed without training. The book of military affairs reads, "The three armies have not moved yet, and the grain and grass come first." We can understand that we are fully prepared in advance. The project is the same. You must specify a training plan at the beginning and allow time for training. I think that unless he is a perfect team, his members must still have something they do nt understand. If there is no training plan and the learning task is pushed down to the personal head, the project risk will become difficult to control. Speaking of training, everyone may think that everyone is sitting there in good order and listening to a teacher in class. This is not the case. The training mentioned here is a broad range of training. It can be a group of courses, a conference, as small as a discussion and a communication. The purpose is to provide team members with sufficient knowledge and skills to complete the project.