Why WanOne models the enterprise before it generates software

“Business Architecture is quite interesting. I suppose it has been mentioned more often in the information age. However, my understanding is that Business Architecture existed long before the information technology era. People were already centralizing and organizing functions from different kinds of daily work. For example, governments created treasury departments, shops specialized in producing and selling food, and manufacturers specialized in producing products. In a way, these practices already reflected Business Architecture principles by abstracting, grouping, and centralizing certain business functions. If you were running a business and providing products or services, this kind of abstraction and centralization was already a form of Business Architecture.”

“Business Architecture is essentially about summarizing and abstracting functionality from many different functions and areas into a clearer structure that serves customer requirements. Two important concepts behind this are generalization and specialization.”

“A lot of people have experience with data modeling, but most of that work is application data modeling for a specific application. From an Enterprise Architecture perspective, Business Data Modeling is different. We may use similar data modeling techniques, but the purpose, scope, and expected outcome are different.”

“Business Data Modeling defines a well-organized container and a clear destination for business information. Its purpose is to establish how business data should be defined, structured, and related across the enterprise. Ultimately, all business information should be represented within this data model in a consistent and organized way. Without a well-organized data model, AI may generate software faster while making enterprise data increasingly fragmented. The Business Data Model provides the foundation that defines and stabilizes this destination, keeping every AI-generated application aligned with consistent business meaning, structure, and relationships.”

“In banking, a bank may operate many different packaged systems, such as deposit management, loan management, credit card, trade finance, mobile banking, ATM, financial management, management accounting, and risk management. At the application level, each system may define and manage its own version of customer data. As a result, customer management can appear repeatedly across deposit, loan, credit card, collateral, and trade systems. From an Enterprise Architecture perspective, however, Customer, or more fundamentally Person and Organization, should be treated as shared business entities rather than being defined independently by multiple applications.”

“Enterprise Architecture uses generalization and specialization to redefine business functionality. However, generalization should not be taken too far. For example, Banking Account across deposits, credit cards, loans, and internal accounts may appear to be the same capability at a high level, but it may not be good architecture to centralize all of them into a single function or system.”

“Business Process Re-engineering often involves the generalization of business functionality. It provides an opportunity to identify similar or overlapping business processes and reorganize them more effectively. However, the core is still business data, because ultimately the outcomes of business activities are captured and represented as data.”

“This approach is not created from scratch. It is based on experience from previous Enterprise Architecture consulting projects, IBM EA methodology, and established enterprise modeling practices. WanOne uses the platform and AI to accelerate both the EA model formation and system generation.”

“L3 Business Activity is similar to a functional module, but at the business level. We summarize and abstract functionality from business capabilities and business data into Business Activities. At L3, we intentionally disregard product features, customer types, and channels. The focus is on identifying the stable and reusable business functionality.”

“L4 represents the Business Process. In the UI, it is presented as a swimlane diagram. At L4, we bring back the factors intentionally disregarded at L3, such as customer type, product, channel, and operational procedures. These factors shape how a Business Activity is actually performed. For example, different channels may require different business processes.”

“L5 is the most detailed business process layer. For each Business Step, you specify what business data is read, queried, created, updated, saved, or deleted. In other words, L5 defines the CRUD interactions between each Business Step and the relevant business data entities and attributes.”

“If you define the Business Data Model, the Business Processes, and how each Business Step manipulates the data, then, as long as the data definitions and business actions are correct, the Business Services can be generated automatically.”

“A Business Service can also be viewed as a Business Capability, because it represents the ability to perform something. In object-oriented design, an object contains attributes and methods. Similarly, in the business world, business data is like the attributes, while a business service is like the method that operates on that data.”

“Once all your Business Services are defined correctly, we move to Application Architecture to choose a service pattern for IT implementation. In the service pattern, endpoint style and runtime engine attach to the pattern.”

“For DB pattern and engine, if you select a DB pattern like shared database, data warehouse storage, or stream state store, multiple database engines may be attached to that pattern. Pattern is one decision; engine is another decision.”

“When we talk about data entities and data attributes, we are using business architecture terms. When we talk about tables and columns, we are using IT implementation terms. Application Data Modeling defines how business data is translated into an implementation data structure.”

“In Data Architecture, the starting point is the data pipeline and data warehouse engine. We have a staging area, an enterprise data warehouse, and an analytics data warehouse — different layers of the whole data warehouse.”

“EDW is the core of the whole data warehouse. It is well organized, well modeled, curated, integrated, and consolidated. At a deeper level, EDW is a kind of mirror of the Business Data Model because we land actual physical data into a similar enterprise model.”

“ADW is different. We define star schemas and analytical subjects. We have fact tables and dimension tables. Dimensions have hierarchies, such as year, month, and day, or country, province, city, and street, so BI tools can drill down and roll up.”

“System Definition is a mapping from architecture into systems. We have already described the business data, processes, services, and their IT realization. Now we decide which frontend application, back-end service, database schema, or warehouse group each part belongs to. In a real organization, these choices should make sense alongside the systems you already have, the teams that own them, and the boundaries for deployment and maintenance.”

“These four types are ways to organize the implementation, not a requirement to create many separate systems. One frontend can serve several actors, and one back-end system can bring related services together. We should split them when ownership, deployment, or maintenance needs a separate boundary—not simply because the model contains many services. Start with a structure you can explain and operate, then separate it when there is a clear reason.”