Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 This email address is being protected from spambots. You need JavaScript enabled to view it.g

Complex vs. Complicated - Part II

1     Complex or Complicated - Basic Principles of Architectural Modeling - Introduction

In my last post, I argued that complexity is a necessary feature of an architecture to ensure stability, "agility". Complex models require complex models and solutions. At the same time, no user wants to have complicated, unmanageable models.

Important fundamental principles to achieve the necessary complexity while at the same time avoiding complexity and ensuring maintainability is the principle of "separation of concerns" and the introduction of defined levels of abstraction. I want to look at that later.

Continue Reading

Complex or complicated - Make complexity your friend

We live in a world of slogans which are just empty. Frequently prominent voices are used for such slogans. E.g., Steve Jobs is often used with his quotes about "creating user interfaces as easy as possible". Many of these quotes are of context and doesn't tell a lot.

Do you think about these examples, everybody agrees, that using a system should be as easy as possible. But in the same way, everybody agrees, that controlling a nuclear power plant with an iPod is not a good idea. The solution has to be in sync with the problem. Sometimes a complex problem has a complex solution.

The slogan sometimes heard in the Business Analysis community "Complexity is the enemy" is not comprehensible to me as our example, that it should be possible to control a nuclear power plant with an iPad. We describe Business Processes taking different views. Sometimes the Flow of Activities, the collaboration of different participants in the Business Process, conformity with legal requirements, automation of parts of the process or complete Business Process are frequent questions. We describe the different views on different abstraction level.

Continue Reading

Agile Teams – Generalists – Specialists – Generalizing Specialists

Agility – Business Agility – Agile Modelling

Some days ago Scott Ambler published a post, talking about “Generalizing Specialists”. (http://agilemodeling.com/essays/generalizingSpecialists.htm).

Even is Scott is talking about IT Skills and Agility in software development, I’m a fan of Scotts ideas and believe that they are also valid and important in Business Analysis. Scott is always formulating to the point. We can learn a lot in Business Analysis too.

The strong separation between „Business Agility” (see „The Business Agility Manifesto“ by R. Ross, R. Burlton, J. Zachmann; https://busagilitymanifesto.org/)  and classical Agile approaches is inexplicable for me. If we talk about digitization and automation, both teams need to work together.

The question of agile development and specialization was raised by me a long period ago already once. (http://model-based-business.engineering/mbbe-blog/98-spezialisierung-vs-agiles-vorgehen-widerspruch-oder-nicht).

 

Agile Teams – Generalists – Specialists – Generalizing Specialists

Especially in the business world we always pretend that Business Analysts are Jack-of-all-Traits, having all skills, able to do everything. I believe that we expect too much from our analysts and miss possible results.

There are more and more concepts of interest. A process is more than a flow; we are interested in flexible, knowledge intense processes. Legal requirements and possible improvements require the systematic management of decisions.

To handle all these concepts we need skills and knowledge about notations and working techniques.

Sure every analyst should know about Business Process Management. But special questions require special skills.

More essential for me the term „Agility“ is associated with working techniques and organization of teams and collaboration.