Systems Flow joins elite group of firms whose IT Architecture methods have been recognized by The Open Group.
Rhinebeck, NY April 23, 2013 – Systems Flow, Inc. announced that the Systems Flow Investigative Architecture™ method has been recognized within The Open Group Certified Architect (Open CA) Program.
“A foundational skill for an architect is the rapid ability to assess and document current and proposed solution designs,” said Dan Hughes, Principal with Systems Flow. “Ensuring our team’s effectiveness and consistency required a structured, repeatable approach for gathering information and capturing it in a clear, concise format to provide clarity and facilitate communication. We developed an architecture method that would go beyond typical examples and templates, combining pragmatic guidance with carefully calibrated diagramming techniques. Our Investigative Architecture™ method not only enables inexperienced architects to ramp up more efficiently, but also allows experienced architects to be more effective and consistent. We and our clients have repeatedly found Investigative Architecture™ to be a highly effective tool for improving technology solution design.”
The Open Group Certified Architect (Open CA) program is an independent global certification program for qualifying the skills, knowledge and experience of IT, Business and Enterprise Architects. In order to be certified, an architect must demonstrate delivery of architecture following an industry standard architecture method. Methods, like Investigative Architecture™, must meet a rigorous set of criteria and be approved by an Open CA Review Board to be recognized. This recognition by The Open Group assures customers and partners of the company’s commitment to vendor-neutral open standards and interoperability, and adherence to proven best practices in Enterprise Architecture.
About Systems Flow
Systems Flow helps organizations dramatically improve their competitive advantage through the practical, effective application of best practices in enterprise architecture and software development. Systems Flow developed Investigative Architecture™ in support of enterprise and solution architecture consulting services. The method has been iteratively refined and improved over the last decade. It has been applied to hundreds of projects to design and document architectures for enterprise-scale clients. For more information please visit http://sysflow.com.
About The Open Group
The Open Group is an international vendor- and technology-neutral consortium upon which organizations rely to lead the development of IT standards and certifications, and to provide them with access to key industry peers, suppliers and best practices. The Open Group provides guidance and an open environment in order to ensure interoperability and vendor neutrality. Further information on The Open Group can be found at http://www.opengroup.org.
Systems Flow, Inc.
+1 (301) 230-1470
We use a system context diagram in the early stages of our Investigative Architecture™ process. It provides a high level functional view of a system and, while it is very powerful for the early stages of functional design, it also ensures you have identified any functional needs that impact the non-functional, or architectural, aspects of the design. Read more
As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. Read more
In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements that creeped into your project.
Too often, however, project managers see the steps in a project from the point of view of items that simply need to be checked off: Read more
We write frequently on this blog about our proven method to deliver IT architectures based on industry-standard tools and approaches like UML and IT Risk Management. We also write about the critical intangible skills that an architect needs to succeed, such as meeting facilitation, diplomacy and organization. One needs to be steeped in all these areas – as well as to form a strong “magic triangle” of technical/business/management skills to really succeed.
This may seem like an odd blog coming from a company that is so deliverable focused, but it isn’t. A design document is not just a document, but a powerful tool for figuring out an architecture. However, it is easy to get caught up in the “task” of completing the design document and lose focus on deeply understanding the architecture.
Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objective of the change, and what are the requirements a change must meet to satisfy the objective.
Implementing the change usually starts with someone needing to know what the change is going to cost!
For practically every profession under the sun there are tools that make the job easier. From bakers to builders, everyone has their choice of implements to ply their trade. Naturally these tools will range from entry level, toy tools to expensive gadgets with more features and sophistication. Enterprise architecture is certainly no exception.
One of our primary tools for designing architecture, of course, is a modeling tool. Modeling tools help us visualize our design into standard, in our case UML, models. There are a variety of these tools in the marketplace, ranging from basic “drawing style” tools to far more advanced suites with “model awareness”, version control, team collaboration capabilities, etc.
Diagramming software systems is still a largely undisciplined activity, despite the many advancements in notation and methodology made over the last 10-15 years.
The typical “Systems Architecture Diagram” profile of a large organization goes something like this: Read more
Risks are part of life. There is uncertainty everywhere. And as more and more of our lives and businesses depend on IT, the risk of IT failures and problems is a critical thing to be able to identify, understand, document and – ultimately – manage.
Architectural Risk is a critical discipline in the Systems Flow process. Its a huge selling point in the “design process” sales pitch we are often called on to deliver, usually not to prospective clients but rather to recalcitrant stakeholders or projects sponsors who need to be convinced to spend time in their projects sorting out architecture and design before diving into coding. Read more