|
29 September 2006 - 20:43
|
|
By now you've probably heard all the latest buzzwords floating around: SOA, BPM, etc. Groups such as Gartner use them to fill their weekly reports. These next-generation solutions all promise more flexibility, maintainability and more business process alignment. Most of these promises are true if we speak about an ideal situation. But in practice it can be whole different. One of the important points is the way the processes are modelled. That can be done in different ways and not every approach will lead to the desired solution. In general: modelling a business process instead of using a programming language to create an IT solution that is easier to understand. But the problems we are solving are the same, so also of the same complexity. The only difference is the level of abstractness we use in defining a solution. So the WAY you define a solution stays important in all methods!
In this article I will explain two different methods used for modelling a business process (in a BPM studio by example). I will also point at some important constructions that make a processe more robust.
When we look at orchestration of (web)services there are at least two fundamental different ways of modelling:
|
21 September 2006 - 15:53
|
|
When you discuss software engineering with people involved in a software project they will generally tell you that they are programming in an object oriented manner. Why? Because they use an OO language (Java, C#, etc). The fact that the language is OO generally leads them to believe that simply using objects means that all their development immediately follows the OO paradigm. My opinion is that OOP isn’t achieved only by using an appropriate language. It’s much more than that!
OOP basically is about modularity.
|
13 September 2006 - 10:16
|
|
Nowadays a lot is written about the discipline architecting. A lot of people use this term whenever it sounds good. In this post I will make a clear distinction between the field of architecting and the field of engineering.
In general, engineering is a deductive process, while architecting is an inductive process. In other words: engineering deals almost entirely with measurables using analytic tools derived from mathematics and hard sciences. Architecting deals more with unmeaserables. It uses nonquantitative tools and experience derived from practical lessons.
I will make this more clear with an overview [1] of the characteristics
|
06 September 2006 - 15:09
|
|
Welcome by The Enterprise Architect. In this weblog I will write about topics in the field of software architecture, enterprise architecture and information architecture. I will also adress some topics on software engineering and enterprise engineering. Last but not least I will critically analyze methods and techniques used in those fields.
I will also,
