It might be a shocking statement, but there are no limits to what Analysis can tackle. Proper Analysis delivers meaningful "models" that you can easily turn into Information Technology (IT) solutions. If you can think of a specific subject matter then you can model it. Therefore you can implement it.
You might have heard people say that too serious UML Analysis may delay your project and even lead you towards what they call "analysis paralysis". You might have even seen organizations shy away from modeling their own problem domain and search around for "some already made" solutions. They say their problem is too big, too complex, too old, and so on. That is how they fail—in reality they could have succeeded.
The problem is not with UML Analysis per se, but in the way some people try to perform the analysis. For instance, a common mistake is trying to "force objects" into the problem at hand. "Hey, we've got to use objects, right?" Wrong. You do not necessarily need a "Marketing" object, or an "Order" object, or a "Customer" object, nor do you need to figure out how they work together using some cryptic UML sequence diagram—at least, not during the Analysis phase.
That approach would be hard and distracting; it would not be UML Analysis. People who try to do it that way give up soon enough. We should not be object-driven or even UML-driven. The driving force behind any Analysis project is the subject matter, or let us call it the Problem Domain. Successful Analysis expresses what your business problem is—not what the technology is.
Translate your business problem domain into a set of artifacts (text and UML diagrams) that naturally and precisely reflect the business subject matter. That will make it possible for developers to automatically turn your artifacts into the proper information system. We will show you the art and science of using a common language—the Unified Modeling Language (UML)—in a way that everyone fully understands: non-technical people and technical people alike.
You need only three things to succeed: knowledge of the subject matter to be analyzed, succinct, specialized UML artifacts (text or diagram), and Business Concept Modeling. We present these artifacts and Business Concept Modeling in all our Analysis courses, especially the UML Business Analysis training course.
Business Concept Modeling is the technique to express your problem domain in a conceptual way. It focuses on all the business concepts, rules and policies. The Business Concept Model (BCM) exposes the most vital information, knowledge and strategy that govern your subject matter. Think of the BCM as "the brain" of your project, the deepest intellectual property of your organization.
You perform Business Concept Modeling mainly using the UML class diagram and some simple specialized text. You can learn BCM in any of our Analysis courses. However, the UML Domain Modeling course will take you to a very advanced level. Take that course and you will be able to model any problem domain that comes your way. This is ideal for top Business Analysts and IT Consultants.
We get non-technical Business Analysts as well as technology-oriented IT Experts in these courses. Business Analysts would typically take our UML Business Analysis, UML Domain Modeling, or OO BPR/BPM training. IT Experts could take any of these courses but specialized developers will be more interested in the OOAD UML Training. The following paragraphs will throw more light to this topic please read on, but you can jump to our UML Analysis Selection Table.
UML Analysis is vital for all Business Analysts who desire to go beyond simple "requirements gathering" and deliver professional artifacts IT Experts will quickly turn into an information system. Here is the big picture:
It all starts with the Stakeholders or Business Visionaries that built a Business Model to implement their Business Vision. The Business Vision is the set of strategy insights that distinguishes a business or organization from others and makes it successful. The Business Model is the set of activities, rules and policies that guide the organization to implement that Business Vision.
The Business Analyst meets these Business Visionaries, studies their Business Vision and Model, and immediately expresses them—or we should say translates them—according to specific artifacts. In this picture we call them Object-Oriented Business Analysis (OOBA) Artifacts. IT Experts will use these artifacts to build or modify the IT System which purpose is to support the Business Model's operations.
The 5-day UML Business Analysis training course we offer trains you to work with Stakeholders and Subject Matter Experts (SMEs) and build these "OOBA Artifacts". There are just five categories of OOBA Artifacts:
This approach is powerful because it uses a small number of highly specialized and succinct artifacts. Yet, taken together they help you comprehend the entire subject matter. Several of them are graphical, which gives your mind a broader, quicker and deeper understanding. Since each artifact is specialized it is easy to build. You will experience how deep your modeling will go and solve the most challenging or sophisticated Business Model requirements.
If you use OO Analysis & UML the way we teach it, you'll find it surprisingly efficient. It succeeds where other approaches routinely fail. You will see that the difference is quite striking with projects that are particularly large or complex. We, when acting as consultants or mentors, have several times been exposed to such projects and succeeded with all of them. Now, it is even more exciting seeing our students succeed.
For instance we've trained several Business Analysts and Software Engineers at "WE Energies", the Milwaukee utility company. Their problem domain is not for the faint-hearted. We call that "The Three Too's": too large, too complex, and too abstract. After their training was over they met 2—4 hours a week, a group made of two non-technical Subject Matter Experts and two senior software engineers.
It took them only a few weeks—maybe 8—to complete their OO Analysis cycle, using UML. That is an actual time of maximum 32 hours—less than one full-time week. Their "Domain Model" is made of approximately 275 concepts and about 1000 concept relationships. It reveals in very great details all the Business Concepts, Rules and Policies that govern most of their entire organization—a staff of approximately 850 people. They manage about 2,800,000 utility accounts.
Design is different from Analysis, yet people often consider them together. If you are involved with development then OO Design is of great importance. If, like many people, you are involved with both Analysis and Design then you might benefit from both OO Analysis and OO Design training. One of our courses offers that, OOAD UML Training. However, you would learn much more by devoting an entire week to each topic. You could, for instance, take a 5-day UML Business Analysis course, then one of our 5-day OO Design courses.
One important thing has to be said about OO Analysis and Design. All the OO Analysis principles are also present in OO Design. To mention a few: Concept Modeling, Encapsulation, Specialization, Interface and Relationships Modeling. So, when you learn OO Analysis you also learn some OO Design fundamentals. Now, OO Design contains several additional fundamental principles and strategies. Examples are: Delegation, Propagation, Object Management, State Management and Behavioral Encapsulation. You can either survey these OO Design principles as offered in the OOAD UML training or cover them in depth in our OO Design course.