Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos
Over the last couple of weeks, I was engaged in a widespread of discussions related to business architecture and other related domains. Typical for those discussions was the usage of specific words, which, in the course of the discussions, required adjacent explanations and adjustments regarding their specific meaning. It was strange, but also remarkable why this so happened.

In the course of discussions the "words of impact" were:

  • - strategic
  • - architecture
  • - standard
  • - components
  • - interface
  • - expertise
  • - coverage
  • - fulfillment
  • - .....

"Let's approach this from a more scientific or engineering viewpoint". This was the typical suggestion during the discussion to increase clarity about the meaning of the used expressions. Progress regarding the content and course of the discussion was achieved as well. This procedure was that supportive that I decide to get some of that outcome to you in this blog.

Buzz words are often used, but besides of "bullish marketing" we have to take care of the implied impact. This attention is required to assure appropriate focus and to limit simultaneous distractive attitudes.

  • If we use the word "strategic" in the sense of "increase of importance", than this it selves (alone) does not change anything regarding content and complexity.
  • If strategic means "new areas" or "new processes" or "changes in organization" or "optimization, efficiency and performance" we have to address this explicitly and provide associated details.
  • It's well known that new processes/services/products and changes in people organizations aren't 100% predictive. To indicate such less-favorable feeling by the word "strategic" is nice, but doesn't solve those issues.

Compared to construction industries the word "architecture" is used in software engineering in a slightly different way. At least this is the perception generated by several publications and discussions. The differences might be there, but this doesn't legitimate the assumption of two complete different fundaments The fundaments which support the handling, the achievement, and the communication of knowledge and expertise.

Both (construction industry architecture and software engineering architecture) domains

  • are built by deterministic research,
  • have several sub-domains,
  • and have a widespread of applications.

There is an exchange of knowledge and expertise among the sub-domains within each of the categories.

Not all scientific approaches are driven by deterministic, fundamental mathematical procedures. There are models built on interaction between predictions and actual. This is the phenomenological approach. Models and knowledge (built in that way) are automatically, continuously approved (by the fact of iteration). The extrapolation capabilities of these models into extended domains are very limited and sometimes rather dangerous. If this is known upfront, nobody will be able to reduce the risk only by predictive assumption. First, the prediction must be validated with a set of measures in reality, before any communication of new "knowledge" can happen.

The words "experimental" and "empiric" are sometimes used as synonyms. That doesn't downgrade experimental science.

Back to business architecture within software: comparing different industries it's more than evident, that matured industries face complete different software issues as immature. Mature in this context is related to standard software packages like ERP, CRM, SCM, and others. Now we might argue that the industries are different and raise therefore the perception, that some of them are difficult. Difficult in this context should be mental minded, not content specific.

Whether content and requirements, market interactions and work-flow scheduling,

  • are disclosed, such people can build knowledge about requirements, coverage, from expertise domains or
  • are very insight and customer specific

This is then a differentiation, but not an indication for complexity.

In the next contribution, I'll highlight the development in Engineering& Construction, Aerospace & Defense over the 80´s and 90`s. Basic message there: "copy and paste, adapt and apply".

2 Comments