It’s been some time ago when I decided to go deeper in the study of IT standards and, somehow, that standards which are supported by a community who make them alive, and doing so, those which are reference blueprints and guides for the community involved. I’ve always thought that the adaptation of ideas are also related with innovation, due to standard don’t perfectly fit in any company and always “new forms and ways” have to be done to adopt them. That is, the binomial “Organization and Standards” is not fixed in its applicability, but the goal itself is knowing an organization, knowing the possible related frameworks within the business in which the organization is involved and try to solve it (or that ones that lacks) and adapt them according to the convenience of it to the company… (generally, adapt them means “lighten” them in early stages). That’s why I deepned and became passionate about Enterprise Architecure standards, after having gone through the different stages of technical architecture, software and applications (previously having come from development), all of this inside architectural domains mixing them with project and human management, procurements, etc… therefore, all of this has make me understand a little bit more Enterprise Architecture and its long spectre and some architectural frameworks which support it, such us TOGAF..
This post’s idea is to introduce, or at least, to leave an idea about association of standards which helps as a guide for professionals who wants to know where to look for and see if the path is solid, or at least, thought by someone previously; of course we already know that there is nothing safe, but if there are many people who have previously thought that something is worth enough, surely we will start from a base that will fit us so as not to reinvent the wheel continuously
Lately, for different reasons, I see how many people who I tried to introduce and talk about EA ideas for quite some time, are closer to them every day, a fact that satisfies me (although this people did it not for voluntarism but for labor). What is clear is that, if it is done by the organization, it is because it has been decided that it is a good investment to provide professionals with this knowledge. Whether they are indicated or not, time will tell, basically if they really value the knowledge they acquire and above all, if they will know how to adapt, apply, communicate and defend them.
So, let’s back to the point of Standards and “laws”; one of the basic principle promoted by The Open Group is Interoperability within the concept of Boundaryless Information Flow™. This concept is basic to think that there is no barriers neither in information nor in technology.
To all of you who knows a little about TOGAF ADM, you know that in phases B, C and D is where “Architecture” is built and iteration betwween these phases, contributes to get a final concrete architecture . So, method is there but…
wouldn`t be interesting to figure out if there is a step of knowledge deeper in each of these phases??
So, that’s the reason of this post… BIF & BoKs.
We already discovered what BIF means…. Boundaryless Information Flow™ and BoK is a broad known and used concept… Body of Knowledge. Then , the concrete question could be…
Is there a Body of Knowledge for a Business Architecture? and for Information and Technology architecture?
From my point of view, the answer is “Yes it is”, and now we’re going to make this matching and a short association.
PHASE B: Business Architecture: BIZBOK
Business architecture represents holistic, multidimensional business views of: capabilities, end to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.
Conceptual scheme for BIZBOK is the one we see below:
PHASE C: Information Architecture: SWEBOK y DAMA-DMBOK
Let’s remember that Information architecture is composed of two different architectures:
- Application architecture and
- Data architecture.
For the first, a broad body of knowledge that we can use as reference, is the one of Software Engineering (SWE-BOK) where main of application issues are covered, in this post we only focus in Design and Development of applications.
Likewise, a well-established body of knowledge that we should have on the radar every time we talk about data is DAMA – DMBOK. I think it is one of the most complete bodies that I have seen and soon we will make a post dedicated to it, since a couple of months ago, the organization DAMA has released version 2
PHASE D Technology Architecture: SEBOK e ITABoK:
Together with SWEBOK, both bodies cover much more than just part of the technology, and are a good reference to investigate them and complement the study of phase D of ADM
Logically, bodies of knowledge cross themselves in different dimensions (for example stakeholders, strategies, design,…), and in the same time they mix with TOGAF ADM;
Now, it is in our power to know how to discern and take advantage of the improvements that each one defends, and then contribute with experiences and added value in their applicability. Let’s think of TOGAF and its ADM as the fundamental basis to enrich it later when we focus on the experiences of the technological domain where we specialize.
Until now, we only are thinking in the iteration of creation of domain architectures, but for the rest of the phases of the ADM, if we want to obtain a complete enterprise architecture view, we could also rely on other bodies from which we could draw advantage…
BABoK is the body of knowledge of business analysts, so surely we can greatly improve the phase of requirements management and Change Management, and of course, the well-known PMBoK, we take adavantage of it in governing the architecure, as well as to achive the final goal as another project, in this case an architecture project.
Sometimes, the architectures projects are not too clear for certain stakeholders who think that simply a project with these characteristics is “to buy more tools”, even deriving that in not enough impulse inside all people involved in the project. Therefore, it is within our hands to understand why standards are essential to achieve a reliable model and , as far as possible, that each architect strives to promote the idea of Interoperability and the use of bodies of knowledge inside Enterprise Architecture… There are more possible bodies to follow, for example for software tests as well as EABoK focused on the subject that concerns us.
I hope that now, when we decide to go deeper into a phase of the ADM in particular, we know that we can always resort to specific resources that will form us and give a broader perspective of the specific field we want to study … I hope I have helped or, at least introduced, the curiosity for those who want to delve into these worlds.
We will “see” in the next blog post, where we will try to analyze the design (using Archimate views) for a field in which there is nothing open “standardized” yet among the different vendors so we will give our proposal and approach … NoSQL Database Design; and in the following one we will link interoperability and data. Hopefully we do not delay so much … changes are like that… :).