Michael B. T. Bell

Last updated
Michael B.T. Bell
Bell bt michael.jpg
NationalityAmerican
Other namesMickey Bell
Alma mater City University of New York
Occupation(s)Novelist, Artist, Producer, Enterprise Architect

Michael B.T. Bell is an American novelist, [1] artist, producer, and enterprise software architect, chiefly recognized for developing the Incremental Software Architecture methodology, [2] service-oriented modeling framework (SOMF), [3] [4] [5] [6] [7] multidimensional software architecture construction (MSAC), [8] and the cloud computing modeling notation (CCMN). [9] His innovative research and publications in the fields of software architecture, artificial intelligence, service-oriented architecture, Microservices, model-driven engineering, cloud computing, cybersecurity, and big data are recognized internationally for their contribution to the software design and development communities.

Contents

Biography

Bell earned his computer science master's degree in 1992 from the City University of New York (CUNY).

After graduation, as a software developer and enterprise architect consultant, he dedicated his career to improving business and technological operations of financial institutions in Wall Street. He developed innovative software algorithms and methodologies for high-volume Electronic trading platforms. This included modules for execution of trading applications, persistence methods for large volumes of data, and design of high-speed network and internet software implementations.

He has worked for J.P. Morgan Chase, Citibank, UBS-Paine Webber, Deutsche Bank, American Express, TD Waterhouse, Pfizer, AIG, Prudential. and United States Department of Veterans Affairs.

Multidimensional Software Architecture Construction

The multidimensional software architecture construction (MSAC) methodology is featured in Mr. bell's Software Architect book [10] published in 2023 by Wiley (publisher). The Software Architect Toolbox section of the book elaborates on two chief views of the MSAC:
1) A quantum software architecture geometrical and topological ecosystem that applications and systems are deployed to
2) Fundamental of 3D software design.

Quantum Software Architecture Ecosystem

The multidimensional software architecture construction (MSAC) introduces an ever-evolving quantum production environment, a Topological space that is subject to geometrical structural modifications during run time and/or design-time.
These changes to the fabric's three-dimensional space of the deployment ecosystem are due to the evolution of architectural environment attributes and the unpredictable behavior of software implementations that affect the production landscape as a whole.
The animated image below depicts a dynamic production environment that hosts software entities and the dents they imprint on its space's fabric.

Multidimensional Software Architecture Construction (MSAC) Ecosystem MSAC-Ecosystem.gif
Multidimensional Software Architecture Construction (MSAC) Ecosystem

Three-Dimensional Software Implementations in an MSAC Ecosystem

Each software implementation, such a software application, service, or system deployed to an MSAC geometrical and topological ecosystem, is represented by three dimensions: width/breadth, length/depth, and height (as illustrated in the below animated image.)

3D Software Dimensions in a Multidimensional Software Architecture Environment MSAC-Soft-Modeling.gif
3D Software Dimensions in a Multidimensional Software Architecture Environment


This 3D implementation model is devised to increase the level of software design specificity needed for construction, deployment, integration, and sustainment in production landscapes. The MSAC methodology is introduced to view and design 3D software constructions in any space, here on earth, any continent, region, or state, and even software deployed to space or other planets.

Each of these software dimensions specifies unique architecture structural attributes in a coordinate system. For example:
Width: granularity, modularity, structural complexity level, source code complexity level
Length: scalability, # of consumers, # of interfaces, computing resource consumption metrics
Hight: software architecture layers, solution stack (technology stack), software architecture environment stack, business or technical capability stack

Service-Oriented Modeling Framework

In 2008 Bell introduced the Service-oriented modeling framework (SOMF) [11] [12] to the software development community in his book Service-Oriented Modeling. [13]

The service framework, driven by Discipline-specific modeling, was devised to encourage consolidation of software assets, reduction of systems redundancy, and acceleration of time-to-market. SOMF [14] includes a modeling language and a life cycle methodology (see image below) suited for narrowing the gap between the business and the information technology organizations in the enterprise.

Service-Oriented Modeling Framework (SOMF) SOMF-3.jpg
Service-Oriented Modeling Framework (SOMF)

The framework also includes modeling disciplines and practices of software systems, for the purpose of designing software applications. Furthermore, SOMF [15] offers a variety of architectural styles, such as enterprise architecture, application architecture, service-oriented architecture, [16] and cloud computing.

Furthermore, SOMF consists of three major segments, as illustrated through the below video clip:
Practices and Modeling Environments Segment. Overlapping Abstraction and Realization Practices with corresponding three modeling environments: Conceptual Environment, Analysis Environment, and Logical Environment.
Modeling Disciplines Segment. Each of the modeling environments contains corresponding disciplines: Conceptual Architecture Discipline, Service Discovery & Analysis Discipline, and Logical Architecture Discipline.
Artifact Segment.This part of SOMF identifies the chief artifacts required for each modeling environment.

Service-Oriented Modeling Framework (SOMF) Three Segments (while running stop to review in details)

Incremental Software Architecture Methodology

Traditionally, to promote the establishment and growth of an enterprise end-state architecture, architects, typically senior IT professionals, deliver a diagram that depicts a future production landscape. [17] In most cases, these software designers claim that such as a "to be" architecture is unbreakable and could sustain rapid market trends and complex technological evolution. Their claim also seems to assure that the illustrated architecture would operate flawlessly in production. Would it?

In many cases, though, such laid on paper architecture, is merely an academic proposition, which later fails to deliver system stability, business continuity, and superb performance. In other words, this speculative architecture tends to break down because of design flaws, and most important—lack of organizational architecture strategy.

To tackle the deployment of failing applications and systems to production and reduce the risk of harming the operating environment, Michael Bell introduced the Incremental Software Architecture approach that calls for submitting bulletproof architecture blueprints. This enterprise design should also be certified by a wide rainbow of organizational stakeholders to dodge financial calamity and business discontinuity.

How is it possible then to ensure that the illustrated design on paper would indeed render a stable production landscape? The term "stable" means that the deployed systems would meet business and non-functional requirements. The promise of the Incremental Software Architecture, therefore, is rooted in the chief principle, "First Design then Develop." But this alone is short of avoiding financial burden caused by failing implementations. Equally important, another related tenet calls for modifying the charter of development organizations: The software construction phase as we know it now, should focus on proving that architecture assumptions would certainly work in production. Bottomline, "software construction must follow the pace of design evolution." Obviously, not the other way around. The term "design evolution" means that architects should drive the product development life cycle, during which the end-state architecture could be incrementally modified, while software construction follows design alterations until architecture maturity is achieved.

To prove that an end-state architecture would indeed operate flawlessly in production, the grand enterprise design should be decomposed into sub-architectures. [18] Such end-state architecture decomposition, therefore, would allow designers to drill down into their detail architecture and enable developers to focus on constructing architecture segments—one at a time, or some in parallel. But proving that each individual end-state architecture segment works as designed, does not mean that the entire enterprise architecture as a whole would indeed perform flawlessly. To verify if an end-state architecture is stable and could endure production environment pressures, an overall architecture stress testing should be considered to assure its stability and fitness.

Consider the Incremental Software Architecture process, [19] as depicted in the provided diagram below:
1. End-State Architecture Discovery and Analysis. Ascertaining systems and related applications in an end-state architecture proposition
2. End-State Architecture Decomposition. The decomposition process is driven by segmenting the enterprise grand design into structural, behavioral, and volatile regions, so developers can prove that these sub-architectures would indeed work in production
3. End-State Architecture Verification. Authentication tasks include design substantiation (software construction,) end-state architecture stress testing, and enterprise capacity planning.

Incremental Software Architecture Process Inc-Software-Arch-Process.png
Incremental Software Architecture Process

Publications

Michael Bell has published several books and articles. The following is a selection:

Related Research Articles

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure of a programming language.

Data engineering refers to the building of systems to enable the collection and usage of data. This data is usually used to enable subsequent analysis and data science, which often involves machine learning. Making the data usable usually involves substantial compute and storage, as well as data processing.

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. SOA is a good choice for system integration. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

<span class="mw-page-title-main">Enterprise service bus</span> Communication system in a service-oriented architecture

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.

Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

The Enterprise Unified Process (EUP) is an extended variant of the Unified Process and was developed by Scott W. Ambler and Larry Constantine in 2000, eventually reworked in 2005 by Ambler, John Nalbone and Michael Vizdos. EUP was originally introduced to overcome some shortages of RUP, namely the lack of production and eventual retirement of a software system. So two phases and several new disciplines were added. EUP sees software development not as a standalone activity, but embedded in the lifecycle of the system, the IT lifecycle of the enterprise and the organization/business lifecycle of the enterprise itself. It deals with software development as seen from the customer's point of view.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing concepts.

Legacy modernization, also known as software modernization or platform modernization, refers to the conversion, rewriting or porting of a legacy system to modern computer programming languages, architectures, software libraries, protocols or hardware platforms. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms to benefit from the advantage of the new technologies.

Service-oriented modeling is the discipline of modeling business and software systems, for the purpose of designing and specifying service-oriented business systems within a variety of architectural styles and paradigms, such as application architecture, service-oriented architecture, microservices, and cloud computing.

Service Component Architecture (SCA) is a software technology designed to provide a model for applications that follow service-oriented architecture principles. The technology, created by major software vendors, including IBM, Oracle Corporation and TIBCO Software, encompasses a wide range of technologies and as such is specified in independent specifications to maintain programming language and application environment neutrality. Many times it uses an enterprise service bus (ESB).

Enterprise engineering is the body of knowledge, principles, and practices used to design all or part of an enterprise. An enterprise is a complex socio-technical system that comprises people, information, and technology that interact with each other and their environment in support of a common mission. One definition is: "an enterprise life-cycle oriented discipline for the identification, design, and implementation of enterprises and their continuous evolution", supported by enterprise modelling. The discipline examines each aspect of the enterprise, including business processes, information flows, material flows, and organizational structure. Enterprise engineering may focus on the design of the enterprise as a whole, or on the design and integration of certain business components.

Business process management (BPM) is the discipline in which people use various methods to discover, model, analyze, measure, improve, optimize, and automate business processes. Any combination of methods used to manage a company's business processes is BPM. Processes can be structured and repeatable or unstructured and variable. Though not required, enabling technologies are often used with BPM.

Middleware is a type of computer software program that provides services to software applications beyond those available from the operating system. It can be described as "software glue".

Oliver Sims was a British computer scientist, former IBM employee, and enterprise architecture consultant, known for his work on business objects Object-oriented programming, and service-oriented architecture (SOA).

<span class="mw-page-title-main">Enterprise Architect (software)</span> Visual modeling and design tool

Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains. It is used by businesses and organizations to not only model the architecture of their systems, but to process the implementation of these models across the full application development life-cycle.

In software engineering, a microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. A microservice-based architecture enables teams to develop and deploy their services independently, reduce code interdependency and increase readability and modularity within a codebase. This is achieved by reducing several dependencies in the codebase, allowing developers to evolve their services with limited restrictions, and reducing additional complexity. Consequently, organizations can develop software with rapid growth and scalability, as well as implement off-the-shelf services more easily. These benefits come with the cost of needing to maintain a decoupled structure within the codebase, which means its initial implementation is more complex than that of a monolithic codebase. Interfaces need to be designed carefully and treated as APIs.

"X as a service" is a phrasal template for any business model in which a product use is offered as a subscription-based service rather than as an artifact owned and maintained by the customer. Originating from the software as a service concept that appeared in the 2010s with the advent of cloud computing, the template has expanded to numerous offerings in the field of information technology and beyond it. The term XaaS can mean "anything as a service".

References

  1. ↑ Michael, Bell (2020). Lost in the City of @. Michael Bell. ISBN   978-0-9896935-6-1.
  2. ↑ Bell, Michael (2016). "The Need for Incremental Software Architecture". Incremental Software Architecture: A Method for Saving Failing IT Implementations. Wiley & Sons. p. 1. ISBN   978-1119117643.
  3. ↑ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN   978-0-470-14111-3.
  4. ↑ Thuraisingham, Bhavani (2010). Secure Semantic Service-Oriented Systems. CRC Press. pp. 42, 43, 152, 153. ISBN   9781420073324.
  5. ↑ Hybertson, Duane (2012). Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems (Complex and Enterprise Systems Engineering). Auerbach Publication. pp. 256, 329. ISBN   978-1420072518.
  6. ↑ Thuraisingham, Bhavani (2013). Developing and Securing the Cloud. CRC Press. p. 87. ISBN   9781439862919.
  7. ↑ Buyya, Rugkumar (2013). Mastering Cloud Computing. Tata McGraw-Hill. pp. 2–30. ISBN   9781259029950.
  8. ↑ Bell, Michael (2023). Software Architect. Wiley & Sons. ISBN   978-1119820970.
  9. ↑ "Cloud Computing Modeling Notation". Sparx Systems.
  10. ↑ Bell, Michael (2023). Software Architect. Wiley & Sons. ISBN   978-1119820970.
  11. ↑ Sosinsky, Barrie (2010). Cloud Computing Bible. Wiley & Sons. pp. 288, 289. ISBN   9781118023990.
  12. ↑ Trujillo, Juan (2010). Advances in Conceptual Modeling – Applications and Challenges. Springer Science & Business Media. pp. 87, 88. ISBN   9783642163845.
  13. ↑ Bell, Michael. "Service-Oriented Modeling". Wiley & Sons.
  14. ↑ Dustdar, Schahram (2010). Service Engineering: European Research Results. Springer Science & Business Media. pp. 112, xi. ISBN   9783709104156.
  15. ↑ Bell, Michael (2009). SOA Modeling Patterns for Service Oriented Discovery and Analysis. Wiley & Sons. pp. 185, 240. ISBN   9780470579695.
  16. ↑ Bell, Michael. "Service-Oriented Architecture". Wiley & Sons.
  17. ↑ Bell, Michael (2016). "The Need for Incremental Software Architecture". Incremental Software Architecture: A Method for Saving Failing IT Implementations. Wiley & Sons. pp. 2, 3, 4. ISBN   978-1119117643.
  18. ↑ Bell, Michael (2016). "The Need for Incremental Software Architecture". Incremental Software Architecture: A Method for Saving Failing IT Implementations. Wiley & Sons. pp. 5, 6. ISBN   978-1119117643.
  19. ↑ Bell, Michael (2016). "The Need for Incremental Software Architecture". Incremental Software Architecture: A Method for Saving Failing IT Implementations. Wiley & Sons. p. 9. ISBN   978-1119117643.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.