• slider3

    A3 KAM - Triple A(Architectural, Actionable and  Augmented) Knowledge Assets Management

  • slider2

    Generalized Enterprise Function Framework  (GEFF)

  • slider4

    ABODE™ business transformation methodology  founded on EA3.0

  • slide1

    Enterprise Architecture 3.0 (EA3.0) - the third wave in Enterprise Architecture approaches

Our Unique Selling Points

Our Unique Selling Points of our total Proposition are as follows:

 

 

Coherence

 

To realize second order change it is necessary that the strategy is translated into the Enterprise Architecture. Thus, the Enterprise Architecture can be the starting position and blueprint for the transformation process. Only Enterprise Architects delivers a method of change called ABODE© in which all aspects of the strategy can be translated into necessary changes into the important aspects of an organization like:

  1. Competences and Culture
    translating the core competences into necessary competences for roles of people in process activities and defining the dimensions of change, including organizational culture change methods of which progress can be measured in an objective longitudinal way
  2. Interaction
    defining the interaction of the organization in a stratified way, from strategic partnerships, to customers which from their lifetime event ask for certain products, and suppliers that interact on fulfilling the supply chain
  3. Behavior
    is realized by processes starting with the interaction with the environment and fulfilled by co-workers and knowledge workers in these processes
  4. Memory
    describes what is necessary to register for later use to support interaction and behavior
  5. Knowledge
    is what the organization functionally needs to fulfil its tasks. Enterprise Architects distinguishes three different types of functional knowledge as described in Knowledge Assets

This Enterprise Architecture (EA3.0) enables the alignment between all parts and aspects of the organization as described in Enterprise Architects3.0 and Model Flow and thus realizing the necessary coherence and consistency of the architecture including the results of the transformation process.

 

Fast Transformation

Direct and thorough Impact Analysis are possible because of the coherent and consistent architecture in which way the necessary Product changes become available in an easy way, based on the Product/Service Architecture. In this way, patterns of change can lead to optimization of necessary components to be developed. Sketches of new User Stories can be translated into definitions of parts of processes and business functions.

 

Enterprise Architects delivers many types of products: Architecture Products and Services and Transformation Products and Services that enable the preparation and execution of different aspects of the transformation process.

 

With our Transformation Tools Enterprise Architects “enriches” business functions with services and business rulesets that are directly executable (DME or Direct Model Execution) and functionally testable. Business Processes can be modeled and use enriched business functions that are “chained together” and can directly be executed and tested. In this way design and development are integrated, including functional testing.

 

In this way new developments can be performed in 60% of the time. This is possible because data access (services) and data manipulation (business rules) take far less time than in original development approaches. Besides that, functional testing can be performed directly after the design has taken place, and adjustments (corrections and user requests) can be made on the fly. This also increases the quality of end-result.

 

When already developed components like Business Objects, Services, and Business Rules are reused the time can be reduced to 10% of the original time.

 

Reuse can also be applied by using earlier developed Business Solution Products in which enriched Business Functions, executable Business Processes, Business Solutions, and Business Models can be reused, adapted, and extended very fast and be used within the new organization.

 

USP: Sustainable development

 

Fast Insight

With our Quick Scan tools, based on our Decision Support Workbench as described in the Assessment Tools Enterprise Architects are able to get fast insight in the condition of Enterprise Architecture or specific domains and aspect architectures of the organization.

 

In this way a Fit/Gap analysis gives insight in how the maturity of the organization’s transformation process can be developed in defined steps.

 

Om meer en gedetailleerder inzicht te verkrijgen zijn op 10 fronten verdiepingsenquêtes ontwikkeld die ervoor zorgen dat de mogelijke knelpunten zoals deze in de Quick Scan zijn gevonden bloot komen te liggen zodat problemen opgelost, uitdagingen aangegaan en flessenhalzen verwijderd kunnen worden. Per onderdeel van de Enterprise Architecture zijn enquêtes opgesteld. In totaal gaat het om 10 samenhangende onderdelen:

  1. Strategievorming & Propositie
  2. Business & Operating Model

USP: Diep inzicht en kennis over knelpunten op specifieke domeinen.

 

Deep Insight

To get a more thorough inside in-depth scans on 10 areas have been developed that enable to find thresholds for change, challenges and bottlenecks that thus can be solved. The following ten related areas are in scope at the moment:

  1. Strategy Development and Proposition
  2. Business and Operating Model
  3. Governance and Enterprise Management
  4. Competence Management
  5. Business Function & Business Rules Management
  6. Business Object and Business Service Management
  7. Business Processes
  8. Organization Development
  9. Knowledge Management
  10. Information Delivery

 

Thorough Foundation

Our transformation approach, products, and services, are all based on the metadatamodel of EA3.0. Through this model all essential components of the business and ICT can be modeled in coherence with each other, described, and be used for further development of business solutions and assessments, enterprise architecture, information management and planning, transformation and lifecycle support.

 

Consistent and Concrete

The metamodel, together with the ModelFlow (see the Downloads area) assures that components are consistent and are most of the times used in more than one model. For example the components of the Proposition Model are used to derive the Conceptual Object Model (COM) and define parts of the Business Function Model (BFM). Next, the Enterprise Objects of the COM are used to limit the Business Objects in the Logical Object Model (LOM) while the Business Functions are “enriched” with Business RuleSets and services. The latter are derived by relating attributes of objects to attributes of other objects (data mapping).

 

Enriched Business Functions can then be executed and functionally tested. Business Processes are modeled by “chaining together” the enriched Business Functions and next the Business Process can be executed and functionally tested. Finally after (part of the) transformation process, the changes of the components of the metamodel are used to describe the new As Is architecture and can be used to refine the impact analysis for coming transformations.

 

So consistent architectural conceptual models are used to derive logical business models that can deliver concrete results. No component of the metamodel is defined without a business and/or ICT goal for business solutions, assessments, architecture, information management and planning, transformation and lifecycle support.

 

Sustainable, Thorough

The integration of the different described aspects of change have proven themselves in executable results. They are stored in the BFM in such a way that they can be found intuitively based on their functionality, they can be reused, changed and executed again for the same or other business functionalities within the organization or the business sector of the organization.

 

 For example, if a solution has been created for a mega bank with several types of banks (wholesale, retail, investment, etc.), for a municipality, a ministry, an ICT service organization, etc. this same solution can be reused, slightly changed, functionally tested and executed for other parts of the mega bank, other municipalities, ministries, ICT organizations, etc.. All this against just a percentage of the cost and time spent, and against higher quality compared to development from scratch. Even compared to solutions like ERP systems, the flexibility of this approach delivers higher quality and lower costs and less effort.

 

Generic Models 

Enterprise Architects Business Models develops generic and specific Business Apps, Business Processes, Business Solutions, and Business Models with our ABODE™ tools.

 

Business Solutions often consist of more than one Business Process. For example, TOGAF or ITIL solutions deliver generic solutions for all larger companies. As none of these companies strictly work conform these standard processes these solutions can easily be adapted according to the requirements of the customer organization.

 

Business Models are even more complex than Business Solutions. They form complete sets of solutions for smaller or larger companies.

 

Enterprise Architects Software Development develops the ABODE™ tools, including generic and specific Technical Interfaces. They can also develop Portals and integrated solutions based on requirements and specifications.

 

De aanpak van Enterprise Architects onderkent drie generieke modellen die op elke klantorganisatie toepasbaar zijn, zij het dat naamgeving aangepast moet worden en dat organisatiespecifieke zaken verder uitgewerkt kunnen worden. De drie generieke modellen vormen de uitgangspositie voor het beschrijven van (huidig en toekomstig) organisatiegedrag.

 

Het betreft de volgende modellen:

  1. Business Events 
    zijn de gebeurtenissen die leiden tot organisatiegedrag
  2. Business Functions
    zijn de activiteiten die elke organisatie uit moet voeren om haar doelstellingen te bereiken
  3. Business Objects
    zijn de gegevensverzamelingen die vastgelegd en hergebruikt moeten worden

 

Omdat bovengenoemde onderdelen van de organisatie niet of nauwelijks veranderen en generiek zijn voor heel veel verschillende typen van organisaties zijn ze bruikbaar als startpunt voor de analyse van de huidige organisatie, maar tevens voor de synthese van de toekomstige, gewenste organisatie. Ze vormen onderdelen voor het organisatiegedrag zonder zelf dit organisatiegedrag te definiëren. Van deze modellen wordt initieel gebruik gemaakt: ze kunnen “geladen” worden voor de klantorganisatie waarbij standaard namen vertaald worden in klantspecifieke namen (bijv. i.p.v. Klant, Belastingplichtige). Hierdoor wordt er snel een brede basis voor de organisatie ingevuld.

 

  • Business Functions
    er is een Business Function Model (BFM) opgesteld gebaseerd op een generiek organisatie model waarbij algemene, strategische, tactische en operationele lagen zijn onderkend, met verschillende geld-, goederen- en gegevensstromen die in totaal meer dan 6000 bedrijfsfuncties (de complete functieboom) bevat; dit generiek BFM dient als basis voor het initieel vullen van het Business Function Model bij klanten
  • Business Modeling
    van hieruit wordt het Business Function Model en het Propositie Model (zie Business Object Modeling) aangevuld met strategische keuzen die via Propositie Model en Business Model leiden tot een Operating Model en een Interaction Model
  • Organization Modeling
    vanuit het Operating Model en Business Processes (verderop) worden de eerste contouren van de organisatie (voor zover aan te passen) gemodelleerd waarbij vooral de volgende zaken van belang zijn:
  • Benodigde Management Systemen
  • Gevraagde Management Stijl
  • Aangepaste Organisatie Cultuur
  • Bedrijfs- en Medewerkercompetenties
  • Event Driven Process Modelling
    een modelleermethode die gebruik maakt van het Interaction Model (Business Modeling) en de Business Functions en door middel van het aaneenrijgen van de Business Function komt tot een eerste specificatie van een Business Process en nog ruwe Business Objects
  • Rule Analysis
    een eerste registratie van functionele Business Rules die nodig zijn om Business Objects te definiëren; vervolgens worden op grond van resultaten van Business Process Modeling, Business Object Modeling en Business Services nieuwe Business Rules gemodelleerd
  • Business Object Modeling
    vanuit een generiek Business Objects model (vergelijk met BFM) worden initieel de Business Objects aangeleverd die vervolgens vanuit Business Functions, Rule Analysis, Event-Driven Process Modeling en tenslotte Business Process Modeling worden aangevuld met zowel functionele als procesmatige gegevensverzamelingen en Business Objects
  • Business Process Modeling
    de door de methode ondersteunde Business Process Modeling wordt gestuurd vanuit de strategische keuzes (Operating Model) en de resultaten van de voorgaande modelleerstappen