Articles tagged with: business architecture

A Conceptual Data Model (aka BIM) is Not Technical - It's about clarifying ...

on Sunday, 28 December 2014. Posted in Business Analysis, Blog

A Conceptual Data Model (aka BIM) is Not Technical - It's about clarifying ...

                                                                                                                                             the business language describing the problem domain so that everyone understand exactly what is meant by the model. And this is something we need to put together independent of the systems or technology— this becomes a road map that helps determine the BIM (Business Information Model) and this output is going to be in the process definition.

 

A conceptual data model identifies the highest-level relationships between the different entities with no technical information like primary keys or attributes.

 

 

 

 

 

 

 

 

 

 

 

 

The figure below is an example of a conceptual data model.

cmmodel

 

The conceptual model helps breakdown for the business stakeholder the planning and to start top-down modeling to do a model driven architecture (MDA).

 

In my view, every enterprise project needs conceptual data models or Business Information Models.Why? 

 

  • It describes exactly the information needs of the business.
  • It facilitates discussion.
  • It helps to prevent mistakes, misunderstanding.
  • It forms important “ideal system” documentation.
  • It forms a sound basis for physical database design.
  • It helps in forming sound logical data and functional models.

 

*** Happy New year , wish you all a great, healthy and extremely happy 2015.

7 Tips to Improve your Project Solution Architecture Outcome

on Wednesday, 23 October 2013. Posted in Enterprise Software , Solution & Business Architecture, Blog

7 Tips to Improve your Project Solution Architecture Outcome

The goal of architecture is to identify the requirements that affect the structure of the application and design a business solution.

 A well thought-out architecture should always consider these important principles:

   Build to change instead of build to last

   Understand the end user needs and the domain before designing components

   Identify sub-systems in your product and consider layers and components to abstract them and identify the key interfaces

   Use an incremental and iterative approach to designing the architecture

   Learn from company history, document your decisions and identify and mitigate key risks

But as we all know: every organization has its share of political drama: personalities clash, diverging agendas. Having worked at many companies here are some thoughts and tips to avoid architecture delays or having your project stopped:

 *** Communicate like you are a Teacher, not a Preacher

 A general assumption, architects are supposed to share their knowledge and experience. Failing to share that information is pretty much against the job description. But how you communicate that experience is the most important part of the job.  Think of your best teachers in school—did they ever go in front of the classroom and tell you how smart they were?  I don’t think so.  They found subtle ways to express their knowledge that encouraged learning and asking questions.

 Tip #1 that I often use , I start my sentences with ‘I think’ this will open discussion items and questions and encourage a two-way discussion.

 Tip #2 Architects are usually quite smart and have a breadth of knowledge but the tone, quality and delivery of the Information is more important than the content, try to always communicate like a teacher .

 

*** Standards apply to Architects, Developers and COE (Center of Excellence)– Don’t take the easy path take the smart path

 Enterprise architects put together standards documents that lay out , architecture patterns, coding conventions, infrastructure, source code nomenclature, and build structures.  But to publish those standardsand fail to hold yourself to them is the highest form of hypocrisy.  If you can’t follow a standard, why would you expect anyoneelse to follow it too?

An example, a company wanted to perform a point (system)to point (system) development, in this case standards existed to use web services with these systems, the development team took a quick decision and coded the point to point development and satisfied the business requirement. The director of the COE (Center of Excellence) did not realize an impact existed onto a surrounding system , the issue caused a security and reconciliation issue. In this case the cost to fix the data & interface was 4 times the initial budget.

 Tip #3 : By applying the standards to your work, you’re respecting the standards of the organization; you also see what will be painful for other groups. Respect your standards and reduce the power politics within your organization.

Tip #4 : Always try to eliminate 'it’s not my job” attitudes at your workplace, especially when you have the role of the architect.

 

***Command from the dugouts, not from the Ivory Tower

Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved.  Instead, these segregated groups architecture and development teams have generated one or more of the following:

 *        Contempt for the architecture because the developers had no say in

the architecture

*        Rejection of the framework because it was impractical to apply to

the project at hand

*        Blatant disregard for the standards set by architects because the architects did not have to respect company deadlines as a result of the delays introduced by their work

 Tip # 5: Architects should be a member of the project team, never as a visiting diplomat to the team.  Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments.

  *** Architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be an architect

 An example, when a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture.  All the while, the architect assists in solving problems that arise from his or her design from a practical standpoint, same as any enterprise software deployment

 In short, the architect’s involvement is continuous, not disconnected.

 Tip #6 : Make sure the architect is involved in the design, build and deployment phase.

 

***Documentation

Tip #7 : Always begin your intervention with a contextual diagram and perform a walk through with the team, don’t write too much text it may cause confusion at the beginning. Developers and implementers interact better with diagrams.

 For architecture projects to succeed there must be a partnership of developers,implementers and architects. Successful partnerships require two way communication and trust, none of which happens when someone acts like God’s gift to mankind, insists on his way or the highway and doesn’t actively get his hands dirty.

Feel free to share your tips , comments and thoughts.

 

 

Business architecture always adapt to your audience - 4 tips

on Thursday, 22 August 2013. Posted in Business Analysis, Solution & Business Architecture, Blog

Business architecture always adapt to your audience - 4 tips

 

Always make a point to understand your audience, audience analysis involves identifying the audience and adapting a speech to their interests, level of understanding, attitudes, and beliefs. Taking an audience-centered approach is important because your material effectiveness will be improved if the deliverable is created and delivered in an appropriate manner.

I have seen many times technical people speaking to the business and not talking at the right level and emphasizing technical information like security, protocols and interfaces. An example application A will push the actuals to application B (good) instead of saying Application A attributes are connecting to table AR_Actuals and the trigger releases the information into Application B table GL_Open_balances. 

Depending on your audience adapt your architecture diagrams accordingly.

In my view, here is a sample architecture of a business architecture diagram that will connect with business savvy people to initiate architecture discussions. here are my tips:

  1. A Business Architecture must be process centric
  2. Be able to apply enterprise-wide architecture and process-level models and techniques that are aligned to your roadmap
  3. Develop a measurable architecture for planning, budgeting, organization design, compliance, human change management, and the introduction of breakthrough technologies
  4. Be able to use an architecture model to accelerate capability change projects and model development

 architecture

 Do you have any favorite tips or would like to share your experience on this topic?

Copyright 2015 Appsconsultant.com. All rights reserved.