Juicero’s flagship product is a $699 countertop device that cold presses juice out of “packs” of already prepped fruit and veggies. The packs — reminiscent of the cups and pouches used in single-cup coffee brewers from Keurig, Flavia or Nespresso — cost $4 to $10 each and are available through a Juicero subscription, but not in groceries.
Juicero just picked up $70 million in Series B funding. ‘Cause digital.
PPOOA – Processes Pipelines in Object Oriented Architectures [website]
Provides a collection of building elements and an architecting process to build component-based architectures, taking into account concurrency issues earlier in the development.
PPOOA is an architecting framework oriented to real-time systems architectures. PPOOA uses two viewpoints: structural, using UML class diagrams extended with PPOOA stereotypes, and behavioral, supported by UML activity diagrams. PPOOA architectures may be evaluated by analytical methods such as RMA (Rate Monotonic Analysis) and simulation tools such as Cheddar tool. An architecting methodology (ise&ppooa) and process is provided also.
TRAK provides a means of describing the architecture of systems, based on the requirements of ISO/IEC/IEEE 42010. Domain-neutral. General purpose for the description of systems, aimed at systems engineers.
TRAK is based on MODAF (UK Ministry of Defence Architecture Framework). It was developed for rail but is domain agnostic and can be used wherever there is a system to be described. TRAK has been designed from the outset to conform to ISO/IEC 42010.
It has 5 perspectives and 22 architecture viewpoints. Architecture view content is defined using tuples (object – relationship – object) with additional rules to enforce consistency across an architecture description, based on a metamodel.
Siemens Four Views
The Siemens approach uses four views to document an architecture. The four views and their associated design tasks are shown in the Figure below. The first task for each view is global analysis. The second and third groups of tasks are the central and final design tasks , which define the elements of the architecture view, the relationships among them, and important properties.
DODAF – US Department of Defense Architecture Framework [website]
To enable “the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.”
IBM IFW – Information Framework
The IFW is a set of banking specific business models that represent practice in banking. It comprises: (1)Information Models: providing banking data content to address areas such as enterprise-wide view of information; (2) Process Models: providing banking business processes content to address areas such as business process re-engineering; and, (3) Integration Models: providing business services content to address areas such as services oriented architectures.
The IFW business models are created by identifying, describing and structuring all of the business functions, data and processes.
When teaching software architecture it is hard to strike the right balance between practice (learning how to work with real systems and painful trade offs) and theory (general solutions that any architect needs to thoroughly understand).
To address this, we decided to try something radically different at Delft University of Technology:
To make the course as realistic as possible, we based the entire course on GitHub. Thus, teams of 3-4 students had to adopt an active open source GitHub project and contribute. And, in the style of “How GitHub uses GitHub to Build GitHub“, all communication within the course, among team members, and with external stakeholders took place through GitHub where possible.
Furthermore, to ensure that students actually digested architectural theory, we made them apply the theory to the actual project they picked. As sources we…
The software engineering community determine several definitions for software architecture. Although each one has specific characteristics, they actually mean the same thing. The Software Engineering Institute (SEI) has collected a large number of definitions of software architecture as can be seen here.
The ISO/IEC/IEEE 42010 was prepared by Joint Technical Committee ISO/IEC in cooperation with the Software and Systems Engineering Standards Committee of the Computer Society of the IEEE in order to addresses the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions. More information here.
The term architecture refers to the rationale and the top-level decomposition of a system (or a set of systems) into its main components and the design process leading to that decomposition. In other words, the architecture of a software system is defined as computational components and the interactions among those components .
Another explanation of the concept is provided by the Software Engineering Institute (SEI), in which the architecture of a software program is defined as “a depiction of the system that aids in the understanding of how the system will behave”. Even further, the software architecture of a system can also be stated as “the set of principal design decisions made during its development and any subsequent evolution”, being the stakeholders responsible for determining which aspects are considered principle .
According to Bass et al. (2003), the term architecture refers to the structure of a system, consisting of software elements, externally visible properties, and the relationships among elements . On the other hand, ISO/IEC/IEEE 42010 defines architecture as fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
We consider that Software Architecture is the discipline responsible for defining the system organization and its components, as well as its internal/external interactions. It also considers the priorities defined by the stakeholders.
The subject is broad, for this reason the figure above presents a simple mind map of the area. Moreover, George Fairbanks presents an introduction to software architecture in the video below. He also highlight the importance of the trade-off related with software architecture using real examples.
 M. Shaw, D. Garlan. Software architecture: perspectives on an emerging discipline. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1996.
 R. N. Taylor, N. Medvidovic, E. M. Dashofy. Software Architecture: Foundations, Theory, and Practice, 1st Edition. Wiley, 2009.
 L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc, 2003.