Some random thoughts on enterprise and software systems architecture, and what comes into mind when dealing with these ...
|
Random Thoughts
Thoughts on architecture and agile method (in the example of SAFe)
So what's the relationship between architecture and agile methods, if there's any? If we take the definition of (system) architecture adopted by many standards organizations, which is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (see ANSI/IEEE 1471-2000 and ISO 42010), then we could rest assured, that whatever is the method or way of developing the software system, it will always have an architecture -- that is, architecture will emerge when we develop the software system. From the studies of the different styles of software architecture we can see that software systems, that peform the same function, can have rather different architectures -- so why to bother? The problem is raised, because apart form the function that software system performs, we often are interested of some other properties of the software system (usually specified as non-functional requirements towards the software system), and because software system architecture is the cause of many important properties of the software system, which are usually requested by several stakeholders. The core of the agile methods is to design and build the software systems piece-wise, but while the functionality of the software system is usually possible to divide into pieces or decompose rather easily, the software system architecture, being a set of global structures, affecting the software system as a whole, does not lend itself to such treatment. Usually some global structures, that define the software system architecture need to be first developed and completely built (at least up to certain level of completeness), to be able to implement the pieces of the functionality (i.e. system functions). SAFe represents the larger pieces of the system functionality (or system functions) by the capabilities, which themselves can be decomposed into smaller pieces of functionality, called features (see Features and Capabilities in SAFE). Admitting the insufficiency of the emerging architecture alone and agreeing to the need for the intentional architecture of the software systems, SAFe proposes an Architectural Runay as implementation of software system architecture (i.e. the code and infrastructure needed to implement the features), which can be itself evolved/extended by implementing the Enablers. So far so good, but to be able to divide the work so that we can build first just a part of the software system architecture, needed for a set of features, we need to be able to map these features onto the software system architecture, for which we need the full architecture designed first. Therefore, in the best case, we can build the implementation of the software system architecture piece-by-piece, but before that we need to design it as a whole. Another slight complication is the global nature of the software system architecture structures -- if for any reason we need to change the software system architecture in such a way that is not supported by the extension mechanisms of the existing architecture of the software system, we need to implement the new software systems architecture an then re-implement/-build all the features that have been built so far (because the system architecture defines how the features are built). All development teams try to avoid later as long as possible, as a very costly exercise. In any way, if the overall software system will be designed and developed as a response to the stream of requirements stated by the stakeholders, the software system architecture will very much depend on the order in which these requirements arrive. ... |
Using ArchiMate for modeling ...
Recently I stumbled upon a strange„feature“ of ArchiMate language that brings some ambiguity intothe models. In the ArchiMate specification (seehttps://pubs.opengroup.org/architecture/archimate3-doc/chap03.html#_Toc10045296) chapter 3.6 is written „The ArchiMate languageintentionally does not support a difference between types andinstances. “. This design decisions brings ambiguityinto the meaning of the diagrams. For example, what is described inthe following diagram: Does this mean that:
There are situations, where it would bepossible to deduce, whether diagram is describing the types orinstances (because for example certain reflexive relationships, like„composition“, would not make sense for the instances), like: But in some cases it wouldbe impossible to know without some indication of what kinds ofelements are in the model or on the diagram, like: Therefore indicate the usageof types or instances explicitly, using for example through ArchiMatespecializations (similar to UML sterotypes) and the naming convention similar to UML, either for the types: or for the instances: Although in ArchiMatespecification it is stated that „At theEnterprise Architecture abstraction level, it is more common to modeltypes and/or exemplars rather than instances.“, there arestill many cases where the model of the actual enterprisearchitecture consists of instances (like capability maps, processmaps, or application landscapes, which all represent certainenterprise portfolios), and therefore it makes sense to clearlyindicate on the diagrams, where are the types (for example whendescribing conceptual models or solution patterns) and where are theinstances, especially if both are mixed on the diagram. |
Hierarchies with the single elements and fixed levels
I have seen many times the which to fix the number of levels in the decomposition hierarchies (like for example in the maps of business capabilities), with the reasoning that it would make things easier by always having known number of levels. One result of this approach is the appearance of branches with single elements oncertain levels. There are such hierarchies, where theelements with just one sub-element will make sense, and there areother hierarchies, where this doesn’t make sense. For example in case of taxonomy, eachelement is representing a set of features – it is a classhierarchy. In the class hierarchy it makes sense to have even singlesub-class for a particular class, because this sub-class represents adifferent set of features than its super-class. It also could make sense in classhierarchy, if needed, to have a fixed number of levels – because oneach level of each branch you have different set of features (which you can distribute evenly). It makes sense to have: On the other hand, in case of functional decomposition,like hierarchy of business capabilities or application components, each element is awhole – it is a composition hierarchy. In the composition hierarchy(which consists of instances, not of classes) it doesn’t make senseto have an element that has only one part, because these are then thesame thing. It makes sense to have: It also would not make sense inthe decomposition hierarchy to have fixed set of levels – becausethis would either enforce the designers to come up with "dummy" levels just to follow the scheme, and results decomposition that is not natural, causing branches with single elements just to „fill“ the levels ofhierarchy, introducing multiple ways to name what actually is the same thing. This is the reason I wouldn't advise tocreate for example business capabilities with only one sub-capabilityor application components with only one sub-component. |
Using models in software development ...
I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all). The reason seems to be that developersdo not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind thereluctance of developers to use models is often the agile movement's argument that everythingcould be seen/found from the code, and because in DevOps same team that does thedevelopment, does also maintenance, there’s also no need tocommunicate between different teams. But actually:
Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable, so often developers and others, involved in the software development activities, try to find other ways tocollect and maintain this additional information, representing it usually in non-formalizedtextual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks). Additional reason to dropmodels in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software tobe represented in machine-readable form. Today still a very big partof the development of business software is solving rather standard/common problems and is filled with the repeatingtasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor),integrations, transformations, reports, etc.), and doing so would economize a lot ofdevelopment time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form. So, the main question is "Dowe want/need to automate also our software developmentactivities?", orwe just want to automate only the various business activities and continue withmanual software development? If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the sameway as for example to automate the credit origination, we need formalrepresentation of customer, loan, collateral, sales process, involved business rules, etc. |
Business Capability – a short clarification
The term “business capability” is synonymous with BIAN “Service Domain” (see BIAN How-to Guide), with “business component”in IBM’s CBM methodology (see Component Business Models), and with “business function” in general business management. A “business capability” describes ability to perform certain set of related activities for providing a set of business services, by combining people, processes, resources(incl. needed systems) and governance, using the business services from otherbusiness capabilities, if needed. Where “business service” describes externally visible unit of business functionality of a business capability, which provides value to service consumers, is provided via explicit external interfaces, and realized by business processes. You can think of a business capability a self-contained part of business that could be outsourced as is. Business capabilities themselves can be hierarchically sub-divided into smaller business capabilities if needed, or combined into larger business capabilities up to a business capability to provide all banking services. Business capabilities are connected through the business services and form a value network. The business capabilities for a given business domain can be found/formulated, taking as the starting point the lists of key activities needed for all the business models of given business domain. The set of business capabilities describes what things given business domain must be able to do, to support the business strategy and execute the business models. |
API vs. ESB (and other related tools)
I would like to clarify some questions related to API management,ESB and specific service interfaces. From one side, API (Application ProgrammingInterface) is nothing more than a specification – a text, containing a set of more or less formal statements, which specify the available (service)operations and data that flows through the interface when these operations areperformed. Therefore managing an API is nothing morethan managing any other formal document – which can be done using any basic text editor or something more fancy, called API management tool, with lots of bells and whistles and with heavy price tag. From another side, ESB is nothing more than a system that transports and routes service requests, and returns matching responses, usually providing several different physical mechanisms to do so, independentof how these service requests are defined or do they together at all form an API. Therefore, if we implement API management tool and ESB, then this will not in any way result in a specific API (or service interface). Developing a specific API is quite time-and resource-consuming task, which needs to be planned and designed as anyother large development. What makes API design even more important, is that API's guide the architecture of future developments and affect strongly their properties. A good analogy here is with DBMS and actual database schema – although we have tools for designing database schemas(e.g. ERwin) and DBMS to run these schemas (e.g. Oracle or TeraData), we cannot assume, that database schema (e.g. for Enterprise DW), suitable for current and future needs just emerges from separate developments. It needs a special (some-time very large) effort, to develop a suitable concrete data-base schema. API design and development requires same way as data-base schema design and development: ・ conceptual models for both functionality (service operations) and data (information), ・ logical models that specify the interfaces, and ・ physical models that specify the interfaces for specific implementation technologies. |
Thoughts on "Architect Your Business - Not Just IT"
When reading MIT CISR Research Brief No 12 from 2014 "Architect Your Business - Not Just IT", I agree very muchwith the statement that “… despite the title, business architects rarely designtheir company’s business.”! The main puzzle forme is, that even when everybody in the organization sees and agrees, that “…their processes, structures, and systems are not providing the agility theyneed …” (i.e. the business architecture of the company is not adequate), I don’tusually see any dedicated effort for designing a new business architecture, notto mention employment of a specialist with business architect skills for doing that. Here I must agreeagain with the statement that “… the dominant design approach for largecompanies is ‘divide and conquer’ in which individual leaders accept responsibilityfor success over a specific set of closely related business activities.”. Because of the Conway's Law, this approach leads to a business and IT architectures that copy the power-structure of the organization. The above mentionedapproach could work, but only if the domains of power and integration/interactionpoints between those separate “kingdoms” are very clearly defined and controlled,and designing these interfaces and controls should be the main task forthe actual business architect. |
Complexity in/of the enterprise architecture
The negative effectsof the overall complexity of business and IT in the enterprise, manifest themselves asunreliability and excessive cost of operations, and excessive cost and time tomake changes. Business complexity has additional negative effects due to the difficulties in selling more complex products and customer dissatisfaction due to unclear and time consuming business processes. Therefore complexity of the business and IT in enterprise needs to be controlled and managed. To be able tocontrol and manage the complexity, we need to be able to measure it. If looking into different treatments of the complexity of systems, we can define the complexity as the number of different elementsand their interconnectedness (number of interconnections between theseelements). Based on such definition, we propose tomeasure business and IT complexity by counting the elements of business(like business models, customer segments, offered products, business functions, business services, business processes, etc.) and IT (like data stores, applications, technologies, etc.), and their interconnections. In both business andIT we can differentiate between:
|
Extending EA meta-models to contain the environment ...
Current EA meta-models describe in great detail the internals of the enterprise, but leave the environment in which the enterprise operates either totally out, or describe it in considerably less detailed way. We should add something similar to the dynamic financial analysis (DFA) models to the EA meta-models, to be able represent the impact of environment to the enterprise, as elements representing competition, markets, regulations, etc. (see for example A. Bergbauer, V. Chavez, T. Fischer, R. Perera, A. Roehrl, S. Schmiedl, Back to the future: Dynamic Financial Analysis (DFA) for decision making, 2004 (Fig. 3), or M. Eling, T. Partnitzke Dynamic Financial Analysis: Classification, Conception, and Implementation, 2005 (Fig. 2), or M. A. Taylor, Business Environment Model, 2013).There are definitely some meta-models, for example Nick Malik's EBMM (contains Influencer) and new ArchiMate motivation extension (contains Driver), which try to deal with the (inconveniences) of outside world, but this is not that elaborate and structured, as these parts of meta-models which deal with inside world. If we see the role of EA function as supporting the orientation of the enterprise according to John Boyd's OODA loop, there is need to have sufficiently good models for both representing and interpreting the environment, and representing and interpreting the enterprise itself. |
Do/should we have "internal customers"?
If we use in the enterprise architecture framework IBM Component Business Model (CBM) and A. Osterwalder's business model canvas (BMC) for describing the business and its parts in a business domainarchitecture.
The CBM can be used to describe the overall businessfunctionality and the functional decomposition of whole enterprise into businesscomponents, which can be viewed as small independent businesses. The businesscomponents in a CBM are connected through the business services that they produceand/or consume from the other business components, forming a value network.Some of those business services are produced and/or consumed by the externalparties (including the enterprise’s customers). So from that viewpoint, for everybusiness component, an external (to the given business component) party couldbe in two different role – customers/consumers of the produced services and suppliers/producersof the required services. The A. Osterwalder’s business model canvas can be used to describethe overall business logic of how the business works for overall enterprise, and/orfor each functional sub-division down to the business components, identified inthe CBM. Business model canvas also identifies external parties in two differentroles – partners and customers. This separation is beneficial because business usuallyneeds to employ different relationship management techniques for the externalparties playing those different roles, and usually also the channels throughwhich the value is delivered to the business, and through which businessdelivers value, are different. Above described conceptual models (together with their language)provide the modularity and encapsulation, needed to manage the inherentcomplexity of the business functionality that whole enterprise comprises. Employing thisview in business organization/operations allows us to achieve self-optimizationof the operations of whole enterprise by optimizing the operations of separate businesscomponents, and robustness by encapsulating the business components behind thewell formed service agreements. In principle we should be able to separate and replace anybusiness component (including IT or its parts) as an independent businessentity, without changing the internal workings of that particular business componentand affecting the operations of overall value network. So in the behavior of a business component, there should notbe any difference, whether the external (to the given business component) partyis also external to the whole enterprise or just another part of the enterprise, but thebusiness component should definitely have different behavior (down to the clearservice agreements) towards the parties to whom it delivers services andtowards the parties that deliver services to it. To avoid confusions with the usage of word “partner” in the A. Osterwalder's business model ontology it would not be good to denote such business components,which do not directly deliver services to the enterprise’s customers, with the sameword “partners”, for both consumers of their services and suppliers of servicesthey need. There might be political reasons for which we want that in our language enterprise’scustomers should stand out from business components that are internal to the enterprise, and because the value network inside the enterprise uses different ways tocount for the value, the word “internal customer” might not be appropriate forconsumers of internal services. So should we then use the word “consumer” throughout the enterprise architecture models/descriptions to denote the businessservice consumers in the business models instead of word “customer”? In case the same business component provides thesame business service to both enterprise’s customers and other business components inthe enterprise (as in many cases IT related business components do), should we treatthose as two different service consumer classes, and use different words todenote these? |
Reducing the complexity and increasign the modularity ...
... of enterprise systems, based on the results from (The Evolutionary Origins of Modularity), could be achieved, by imposing an additional cost (a kind of "tax") upon the direct connections between the enterprise systems.
Reserves created from such "tax", could be invested into the improvement activities of enterprise architecture. |
Controlling the enterprise (IT) architecture
We can control/develop enterprise (IT) architecture by following:
|
Measuring the Effect of Enterprise Architecture
Some things that can be measured for estimating/following the success of enterprise architecture activities:
|
About the requirements analysis ...
Because every requirement has a price attached (in terms of time and money), they should be handled with care and precision (as money is handled). |
About freedom ...
IT people use Android, but business people use Apple iOS.
Both want freedom, but these are two different freedoms:
|
What system aspect is above others – who rules in governance ...
I don’t want to put all the modeling disciplines into the information modeling (as sub-domains) just because most of these are somehow related to information modeling, or just because we can view any modeling activity itself as information processing activity. For me information modeling is part of the larger domain of modeling the structural aspects of the domains or systems, and answers in this context to the following questions:
It is important to have in mind that because different modeling disciplines cover different aspects of the system under study, we get the full holistic picture only by applying several modeling disciplines, not by putting one discipline above others – real world systems have both structure and behavior at the same time. That is why I would like to see that neither information owner nor process owner are ruling over each other in information or process governance – the governance should be set over full picture that describes all aspects of given domain or system (EA in case the system is the enterprise). To achieve the consistency, stability and encapsulation, there is no need to try to establish global governance over all levels, just higher level composition owner should govern the interfaces (incl. both structure and behavior) between the next level components – doing so we are able to partition the models to fight the complexity, and allow freedom of development/governance inside the components. |
Business components solve problems of process-orientation
Most of the problems in process-orientation come from the fact, that processes are viewed as global artifacts independent and above of functions (business components). Hence for example the problem of cross functional processes and lack of authority of process owners in the organization. If we would build the whole enterprise using component orientation -- that is encapsulate the processes inside business components, and allow only interactions of business components based on well-defined interfaces (SLAs), then there will be no such problems, as every process owner is in full control of its processes and resources needed to perform these. Additionally enterprise would be way more agile (and self-organizing), as responses to the possible changes are localized into the components, any components can be replaced with the best in industry (outsourced) without any adverse effects to business as whole, and the global flows of activities will adjust themselves to the optimal in given context. If you look from the customer's perspective, then processes are encapsulated inside the component with which you interact. For example if customer requests for loan offer from sales component, and receives the response from sales component, then it doesn't matter to him/her what other business components are involved and how. In this case sales component management is completely in charge of the process which is used to produce the response (or service), as it is not crossing borders of component, and component management has SLAs for all the services that it needs/uses from other components -- so there is no need for matrix-organization (with the dual and often conflicting command lines) at all. To the sales component doesn't actually matter how (using what process) the underwriting is done by the risk management component as long as the SLA for underwriting is not breached. |
Software "stack" -- business logic and reusable assets
Software "stack" -- separation of concerns:
(A business function is a function that gives business benefit to the user, it is often specified/described by a business use-case.) Guidelines for implementing and packaging business logic and reusable assets:
|
How to start describing business (architecture)
|
Specifications and actuals (and UML powertypes)
What I have in mind, is the duality of concepts in the domain, where:
Both sets of concepts being on the same modeling level, and always have at least one-to-many relationships between each other. The difference of specification from the actual is, that specification can, and in many cases do exist without corresponding actuals. Also specifications have usually own behavior, which is different from behavior of actual. Participants of this (pattern?) could be represented in models using corresponding stereotypes, or just grouping these together on diagrams. This pattern has helped me to identify concepts/relationships, and to organize the model. Maybe this would be possible to model using UML powertypes, but I would avoid mixing different modeling levels (model, meta-model, ...) in the same model, and would prefer to use stereotypes instead of these (to show that certain classes are from given class denoted by stereotype). If we want to model the business rules for meta-model elements, then we should have a separate meta-model, that shows the specialized elements and respective rules/constraints attached to these. This distinction in modeling levels is good to be maintained also into the solution, down to the physical models -- that is if we choose to have dynamically configurable system, then from the meta-models we derive the physical models representing the configuration information, and from the models we derive the actual content of configuration information for the system. Failure to make this distinction clearly is the source of problems in maintenance of dynamically configurable systems. What Fowler describes as specification pattern seems to me too narrowly applied only for selecting objects from object sets, but maybe I am mistaken. |
On EA function and the "customer" of EA
Gartner Pub. "Develop Next-State Enterprise Architecture to Improve Usability" states: "Too many EA programs are suffering because their content is being largely ignored by some of the very people they are trying to serve -- project teams." Is it really so that EA program is trying to or must serve project teams? I would argue, that the main purpose of the EA programs is not to serve, but to constraint the project teams -- doing so of course in the name of serving the whole enterprise including the project teams, but still the main purpose is to impose the constraints that restrict the project teams. It is the same, as police is establishing speed limits for motorists -- for benefit of whole society some of the members need to be restricted in their doings. This of course doesn't mean, that restrictions/constraints developed by EA program, doesn't have to be "actionable" and "pragmatic". The detail level and overall nature of restrictions/constraints has to match the maturity of project teams -- by analogy, for small children the restrictions must be very precise and categorical, but when dealing with grown-ups you can rely on some level of common sense (or maybe not).<7p> ... The overall question is about the primary stakeholder/counter-party -- who EA function serves. Does the EA function serve management in development of enterprise, working for global goals, or does it serve the project teams, working for local goals? I would focus more on serving the management and global goals, because project teams are already served by the application architects. There was an important remainder in the article -- you can't have road map (next steps), before you have future state! |