Aligning Business and Technology

Our customers see value in high level views


Why us?

We examine your business processes and supporting technology from an Enterprise perspective.



Decision makers spend a lot of time reading reports and seeking clarity. Finding a clear view of the relationship between business goals, data, applications and infrastructure is challenging. Challenging because most organizations do not have dedicated thought partners focused on high level perspectives. We discover how your technology aligns with your business and communicate that in a consumable package for decision makers.

Learn more


Applications are chosen to support business needs. Organizations understand a specific business need. Organizations can find applications to meet that need. However, organizations are not clear on how the business need and application support the Enterprise. Applications are one component of a holistic organizational view. OTC, third party, or custom, we provide development, proposals, pilots, and recommendations focused on supporting your Enterprise.

Contact us


From our perspective, data is closer to your business than applications or hardware. Data is the blood of your business inputs and outputs. Structuring, delivering and stored data in a manner that aligns with your strategic plan is our talent. We can build data architectures that guide your Engineering and IT teams on a path to efficient report delivery and solution development.  

Get started
Data Level


A data architecture aims to set data standards for all its data systems as a vision or a model of the eventual interactions between those data systems. Data integration, for example, should be dependent upon data architecture standards since data integration requires data interactions between two or more data systems. A data architecture, in part, describes the data structures used by a business and its computer applications software. Data architectures address data in storage, data in use, and data in motion; descriptions of data stores, data groups, and data items; and mappings of those data artifacts to data qualities, applications, locations, etc.

Essential to realizing the target state, data architecture describes how data is processed, stored, and used in an information system. It provides criteria for data processing operations to make it possible to design data flows and also control the flow of data in the system.

The data architect is typically responsible for defining the target state, aligning during development and then following up to ensure enhancements are done in the spirit of the original blueprint.

During the definition of the target state, the data architecture breaks a subject down to the atomic level and then builds it back up to the desired form. The data architect breaks the subject down by going through three traditional architectural stages:

  • Conceptual - represents all business entities.
  • Logical - represents the logic of how entities are related.
  • Physical - the realization of the data mechanisms for a specific type of functionality.


Despite the plethora of patterns that have been published, there are relatively few patterns that can be thought of as "industry standard". Some of the best-known of these include:

  • single-tier/thick client/desktop application (structural pattern): an application that exists only on a single computer, typically a desktop. One can, of course have the same desktop application on many computers, but they do not interact with one another (with rare exceptions).
  • client-server/2-tier (structural pattern): an application that consists of a front-end (user-facing) layer running as a rich client that communicates to a back-end (server) which provides business logic, workflow, integration and data services. In contrast to desktop applications (which are single-user), client-server applications are almost always multi-user applications.
  • n-tier (structural pattern): an extension of the client-server pattern, where the server functions are split into multiple layers, which are distributed onto different computers across a local-area network (LAN).
  • distributed (structural pattern): an extension of the n-tier pattern where the server functions are distributed across a wide-area network (WAN) or cloud. This pattern also include some behavioural pattern attributes because the server functions must be designed to be more autonomous and function in an asynchronous dialog with the other functions in order to deal with potentially-significant latency that can occur in WAN and cloud deployment scenarios.
  • horizontal scalability (structural pattern): a pattern for running multiple copies of server functions on multiple computers in such a way that increasing processing load can be spread across increasing numbers of instances of the functions rather than having to re-deploy the functions on larger, more powerful computers. Cloud-native applications are fundamentally-based on horizontal scalability.
  • event-driven architecture (behavioural pattern): Data events (which may have initially originated from a device, application, user, data store or clock) and event detection logic which may conditionally discard the event, initiate an event-related process, alert a user or device manager, or update a data store. The event-driven pattern is fundamental to the asynchronous processing required by the distributed architecture pattern.

The right applications pattern depends on the organization's industry and use of the component applications. An organization could have a mix of multiple patterns if it has grown both organically and through acquisitions.

Application Level
System High Level


The term "business architecture" is often used to mean an architectural description of an enterprise or a business unit, an architectural model, or the profession itself. The Business Architecture Working Group of the Object Management Group (OMG) (2010) describes it as "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands."[4] According to the OMG, a blueprint of this type describes "the structure of the enterprise in terms of its governance structure, business processes, and business information."[5] As such, the profession of business architecture primarily focuses on the motivational, operational, and analysis frameworks that link these aspects of the enterprise together.[4]

The key characteristic of the business architecture is that it represents real world aspects of a business, along with how they interact. It is developed by an interdisciplinary practice area focused on defining and analyzing concerns of what business does, how it does it, how it is organized, and how it realizes value.[6] It is used to design competitive structures and processes, leverage existing strengths, and identify potential investment opportunities that advance the business's objectives and drive innovation.[7] Products of this business architecture efforts are used to develop plans, make business decisions and guide their implementations.[6]

In practice, business architecture effort is conducted on its own or as part of an enterprise architecture.[6] While an enterprise architecture practice in the past had focused primarily on the technological aspects of change, the practice is quickly evolving to use a rigorous business architecture approach to address the organizational and motivational aspects of change as well.[7] The alignment between business architecture and enterprise architecture is a natural architectural alignment of two related disciplines. Business architecture represents a business in the absence of any IT architecture while enterprise architecture provides an overarching framework for business and IT architecture.[8]

  • Plex Sytems ERP

    Submitted by gogi on Sun, 03/08/2020 - 02:43

    Our manufacturing expert had the opportunity to take a look at a deployment of the Plex Manufacturing System. Like many enterprise solutions they do many things. But only a couple are done well. We found that the Business Management Modules were of medium effort to deploy and worked to expectations. The modules related to manufacturing seem adequate. They do require more customization and the help of an outside consultant. In particular, the Inventor Management module does have off the shelf integration components to keep track of consumed items.

  • What Happened to the Visual Studio License?

    Submitted by gogi on Sun, 03/08/2020 - 02:42

    Years ago developing on the MS plaform was  an exclusive activity. First you needed a version of Visual Studio to write code and compile it. That alone ran about 2500 per year. At the time MS had a licesning agreement that gave them rights to all code compiled using VS. It was and elitist club indeed. So what happened? Like capitalism tends to do, people were driven to innovation to free themselves from code tyranny. Hence Mono arrived on the scene. Mono is a compiler that works with MS languages thus removing some of the licensing shackles.

  • The End For Bitcoin Draws Near (SegWit2x)

    Submitted by gogi on Sun, 03/08/2020 - 02:42

    The Blockchain algorithm is running without issue on nodes across the globe for nearly two decades. Like all things technology, the time comes for an upgrade. That time has arrived for the Blockchain. SegWit2X is an upgrade to the Blockchain set to deploy on the Aug 1, 2017. The upgrade will double the size of the block and increase the Bitcoin network performance which is very much in need now and more so in the future. So, what is the problem? Just click the upgrade package and wait for it to install. There is fear that some crypto current platforms will not support the new blocks.

  • Working with Sitefinity MVC Widgets (Pure, Hybrid or Classic)

    Submitted by gogi on Sun, 03/08/2020 - 02:41

    We are currently building custom MVC widgets for a client, and noticed a couple of things. First is that the development environment with Sitefinity Thunder is not the best. The provided Visual Studio project is part of the site installation. Since this client pushes content changes from their development installation, we would have to work from the same site. Work would be checked from the physical site and not in a development environment.  This slowed us down a great deal.