Content deleted Content added
The introductory paragraph is essentially information-free, presumably except to those who work very closely with these concepts, or know what any of them are. |
m Dated {{Confusing}}. (Build p612) |
||
Line 1:
{{Confusing|date=May 2011}}
A '''Functional Software Architecture''' ('''FSA''') is an architectural model that identifies [[Enterprise architecture|enterprise]] functions, interactions and corresponding [[Information Technology|IT]] needs. These functions can be used as reference by different [[___domain expert]]s to develop IT-systems as part of a co-operative information-driven enterprise. In this way both [[software engineers]] and enterprise architects are able to create an information-driven, integrated organizational environment.
Line 16:
Especially in the field of software engineering many tools (A4 Tool, CAME, [[ARIS]]), [[computer languages|languages]] (ACME, Rapide, [[Unified Modeling Language|UML]]) and methods ([[Dynamic Systems Development Method|DSDM]], [[RUP]], [[ISPL]]) are developed and extensively used. Also, the transition between the software engineers (step 3) and computer programmers (step 4) is already highly formalized by, for instance, [[object-oriented]] development.
Setting strategic objectives (step 1) and the corresponding search for [[business]] opportunities and weaknesses is a subject extensively discussed and investigated for more than a hundred years. Concepts like [[Business process reengineering]], [[Product software market analysis]], [[Requirements analysis]] are commonly known and extensively used in this context. These strategic inputs must be used for the development of a good enterprise design (step 2), which can then be used for software design and implementation respectively.
Recent studies have shown that these enterprise architectures can be developed by a number of different methods and techniques. Before these methods and techniques are discussed in detail a definition of an [[Enterprise architecture]] is given:
:''An Enterprise Architecture is a strategic information asset base, which defines the mission, the information necessary to perform the mission and the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs.''
Line 26:
==Development of an FSA==
As the boundary of an enterprise is extended, it becomes increasingly important that a common “big picture” of needed business, people and IT system activities is developed and shared by all the parties involved.<ref name="Kim">Kim & Weston & Hodgson & Lee (2002); The complementary use of IDEF and UML. Information system engineering, Deajon University South Korea, Computers & Industrial Engineering 50, 35–56.</ref> A Functional Software Architecture does this by breaking down the organization in business functions and corresponding IT needs. In this way the enterprise engineer provides a rich schematic reference that can be used by the software engineer in the development of these IT-systems.
The development of a Functional Software Architecture can be done by a number of (combined) methods and techniques. Filling in the “gap” between the enterprise engineers and software engineers through the use of different combinations of methods and techniques will be the main objective. However, this objective can only be reached when combined methods result in clear and rich functional software architectures that are developed and used by both parties.
Optimizing the internal and external business processes through process reengineering is one of the main objectives an enterprise can have in times of high external pressure. A [[business process]] involves value creating activities with certain inputs and outputs, which are interconnected and thereby jointly contribute to the final outcome (product or service) of the process. Process reengineering covers a variety of perspectives of how to change the organization. It is concerned with the redesign of strategic, value adding processes, systems, policies and organizational structures to optimize the processes of an organization.<ref>Zakarian & Kusiak; Process analysis and reengineering: Department of Industrial Engineering, University of Iowa, USA, Computers & Industrial Engineering 41, 135–150</ref>
Line 45:
===Computer Integrated Manufacturing Open Systems Architecture===
[[CIMOSA]] provides templates and interconnected modeling constructs to encode business, people and IT aspects of enterprise requirements. This is done from multiple perspectives: Information view, Function view, Resource view and Organization view. These constructs can further be used to structure and facilitate the design and implementation of detailed IT systems.
<!--missing figure-->
Line 51:
===Integrated DEFinition===
[[IDEF]] is a [[structured modeling]] technique, which was first developed for the modeling of manufacturing systems. It was already being used by the U.S. Airforce in 1981. Initially it had 4 different notations to model an enterprise from a certain viewpoint. These were [[IDEF0]], [[IDEF1]], IDEF2 and [[IDEF3]] for functional, data, dynamic and process analysis respectively. In the past decades a number of tools and techniques for the integration of the notations are developed in an incremental way.
IDEF clearly shows how a business process flows through a variety of decomposed business functions with corresponding information inputs, outputs and actors. Like CIMOSA, it also uses different enterprise views. Moreover, IDEF can be easily transformed into UML-diagrams for the further development of IT systems. These positive characteristics make it a powerful method for the development of Functional Software Architectures.
===Petri Nets===
[[Petri Net]]s are known tools to model manufacturing systems.<ref>Silva, M. and Valette, R. (1989); Petri nets and Flexible manufacturing. Lecture Notes on Computer Science, 424, 374–417.</ref> They are highly expressive and provide good formalisms for the modeling of [[concurrent system]]s. The most advantageous properties are that of simple representation of states, concurrent system transitions and capabilities to model the duration of transitions.
Petri Nets therefore can be used to model certain business processes with corresponding state and transitions or activities with in and outputs. Moreover, Petri Nets can be used to model different software systems and transitions between these systems. In this way programmers use it as a schematic coding reference.
In recent years a number of attempts have shown that Petri Nets can contribute to the development of business process integration. One of these is the Model Blue methodology, which is developed by [[IBM]] Chinese Research Laboratory and outlines the importance of model driven business integration as an emerging approach for building integrated platforms.<ref>Zhu et al. (2004); Model-driven business process integration and management: A case study with the Bank SinoPac regional service platform, IBM Corporation, Res. & Dev. Vol. 48 No. 5/6.</ref> A mapping between their Model Blue business view and an equivalent Petri Net is also shown, which indicates that their research closes the gap between business and IT. However, instead of Petri Nets they rather use their own Model Blue IT view, which can be derived from their business view through a transformation engine.
Line 66:
===Enterprise Function Diagrams===
EFD is a used modeling technique for the representation of enterprise functions and corresponding interactions. Different business processes can be modeled in these representations through the use of “function modules” and triggers. A starting business process delivers different inputs to different functions. A process flowing through all the functions and sub-functions creates multiple outputs. Enterprise Function Diagrams hereby give a very easy-to-use and detailed representation about a business process and corresponding functions, inputs, outputs and triggers.
In this way EFD has many similarities with IDEF0 diagrams, which also represent in a hierarchical way business processes as a combination of functions and triggers. Difference is that an EFD places the business functions in an organization hierarchical perspective, which outlines the downstream of certain processes in the organization. On the contrary, IDEF0 diagrams show responsibilities of certain business functions through the use of arrows. Also, IDEF0 has a clear representation of inputs and outputs of every (sub)function.
| |||