BizzDesign Staff – Page 10

Enterprise Architecture Roadmap for success: Project based implementation

January 29, 2013 by BizzDesign Staff

This is the sixth posting in our “Enterprise Architecture Roadmap for success” series. In this posting we zoom in on the implementation and embedding of an enterprise architecture practice in an organization. <div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600376-Enterprise-Architecture-Roadmap-for-success-project-based-implementation.png” alt=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” title=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” width=”600″ height=”376″/>Enterprise Architecture Project based implementation</div> </div><div class=”captionImage left” style=”width: 600px;”><h2>Enterprise Architecture is everywhere</h2>In one of our discussions during a client engagement we came across the following remark by one of the Enterprise Architecture’s in the organization: “Enterprise Architecture is about everything the organization is and does”. This remark supports our experience, and is one of the reasons that many companies struggle to effectively adopt and embed Enterprise Architecture in their organization. Enterprise Architecture has many stakeholders and, depending on the approach taken i.e. top-down or bottom-up, from various levels of the organization.Enterprise Architecture touches on many aspects of the organization such as business and IT alignment, strategic portfolio management, project management, and risk management. Enterprise Architecture is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of Enterprise Architecture in the organization is typically approached as a project: with clearly defined goals, metrics, stakeholders, and appropriate governance, accountability, and with assigned responsibilities in place.<h2>Evolution rather than revolution</h2>From our experience, the road to a strong, effective, and mature Enterprise Architecture capability should be broken down into manageable pieces. We favor evolution, rather than revolution. Too many times we have seen initiatives fail due to the sky high expectations to be delivered within unrealistic time frames. Implementing Enterprise Architecture is a change initiative that besides processes, tools and other hard and tangible artifacts includes many “soft aspects”. These soft aspects need to be managed as such, involving mainly frequent, clear and honest communication with feedback and iteration.<h2>Where to start?</h2>The first step is to decide on the ultimate goal for the Enterprise Architecture function: where is the Enterprise Architecture organization positioned, who are the most important customers of Enterprise Architecture, and how does Enterprise Architecture deliver value to its customers? In the first postings of this series, the ones in the “aiming” category, we covered a number of important choices for the organization to take: are we following a bottom-up, or rather a top-down approach? How does Enterprise Architecture tie into strategy, project management, the corporate governance framework, and security?Depending on the approach chosen, the next thing to do is to establish a project team that will be tasked with drafting high level plans for the implementation and embedding of the Enterprise Architecture capability in the organization. The plans should describe a long-term (say 3-4 year) strategic vision for the Enterprise Architecture capability, as well as a plan outlining the concrete initiatives for the short-term (say the first year).It is one of the important tasks for the Architecture Board to provide input for the strategic vision for the architecture function, and then select the right members for the project team (see also the previous posting on “<a title=”the role of the enterprise architecture board” href=”http://blog/ea-roadmap-for-success-the-architecture-board/”>the role of the architecture board</a>”). The team should reflect the various areas and domains of the architecture, and the members should be able to look at the organization on a higher level, above the individual silos. The project team should interact with the AB frequently to make sure the efforts of the team keep aligned with the envisioned direction. In the next posting we will delve into more details around the Enterprise Architecture project team.<h2>Kicking off the project</h2>Once the team and high level plans are in place, it is time to kick off the project. The team will take the high-level plans and preliminary decisions, such as the proposed architecture framework as a starting point, and from there make more detailed plans and start identifying and prioritizing a number of initiatives. These first initiatives should not be seen as “architecture” projects per se, but rather pertain to the question: “how do we do architecture”. Or, according to TOGAF9: “where, what, why, who, and how we do architecture”.Aspects in this context that need to be determined and confirmed in the first phase are (not complete!):<ul><li>Scope</li><li>Stakeholders</li><li>Requirements</li><li>Relationship between management frameworks</li><li>Maturity assessment of required capability</li></ul>As mentioned before, these aspects should be considered both from a strategic, long-term perspective, as well as from a short-term perspective. This, together with the general approach for Enterprise Architecture chosen (e.g. bottom-up, or top-down) determines priorities and thus the order in which things should be done. For example, detailing and determining interaction of EA with other management frameworks should be done for the project management framework earlier and in more detail if a bottom-up approach is followed.The exercise of determining scope and assessing current and desired maturity leads to a roadmap for the development of the architecture capability. With the order of activity based on various indicators such as approach chosen, prioritization, organization culture, sponsorship, etc. This road map guides the Enterprise Architecture project team in their day-to-day activities. It is a task of the AB to make sure that the road map remains accurate and aligned with business strategy. The road map should be assessed frequently, say each half year, and necessary changes should be made accordingly.<h2>Using the TOGAF ADM to develop an Enterprise Architecture capability</h2>To conclude this posting we would like to point Enterprise Architecture project teams, especially in organizations that chose to adopt the TOGAF to an interesting section in the standard. In chapter 46, TOGAF describes how the ADM (Architecture Development Method) can be used as a tool to implement an Architecture Capability. In this approach, the “business architecture” of the Enterprise Architecture capability involves the organizational structure of the Enterprise Architecture capability, and architecture processes such as governance. The “data architecture” pertains to the meta model, and the Architecture repository that the Enterprise Architecture capability uses to describe architecture, and store architectural artifacts. The “application architecture” and the “technology architecture” describe functionality and the tools (modeling tools, document management systems, etc.) that need to be deployed to support the architecture capability. Using a structured approach as suggested in the TOGAF standard helps an architecture team to draft complete and clear plans. A number of iterations of the ADM can be defined to evolve the maturity of an EA capability.<h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers the establishment of an EA team. It is scheduled to be posted between february 11th and february 15th. </div>

Designing secure organizations. Risk management, Enterprise security management and ArchiMate.

January 21, 2013 by BizzDesign Staff

No one is allowed to enter the building without proper authorization; all incoming e-mail messages are filtered; personal computers that are used to store sensitive data do not have a direct connection to the internet, and therefore cannot be accessed remotely. With these enterprise security rules, we have ensured that our private information is safe, right? Wrong! Cyber-attacks are getting increasingly sophisticated, using a combination of digital, physical and social engineering techniques. A typical example is the so-called “road apple attack”. A would-be intruder “accidentally” leaves a USB flash drive – with company logo – in a public spot such as the company car park. An employee picks it up, and chances are that he will not be able to suppress his curiosity and plug it into his PC. Surprise: the drive is infected with malware which, unless proper measures have been taken, will infect the PC and send sensitive information to the intruder.<img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600395-Risk-Management.png” width=”600″ height=”395″ alt=”” title=””/> Of course, there are several ways to prevent this from happening. The system administrator may decide to completely disable the use of USB drives, but perhaps this is too restrictive, causing employees to find ways to circumvent this. Or perhaps a policy against the use of unverified storage devices suffices, if people are disciplined enough to comply with it… There is no easy way to determine how much security is enough, and how much is too much. In other words, how do we find the optimal position on the trade-off between security, usability and costs?Most of the present-day security and <a title=”risk management, secuirity measures” href=”http://www.bizzdesign.com/consultancy/governance-risk-and-compliance/”>risk management </a>approaches are based on checklists, heuristics and best practices. Security measures are applied in a bottom-up way, often neglecting the social aspects. This may lead to an overkill of preventive security measures, also in cases where cheaper (and less intrusive) curative measures may suffice. On the other hand, less obvious threats or vulnerabilities in the organization may easily be overlooked. <div class=”captionImage left” style=”width: 424px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-security-management-ArchiMate.png” alt=”Enterprise Secuirity Management” title=”enterprise security management, model-based approach ” width=”424″ height=”458″/>enterprise security management, Archimate core</div>To avoid this, we advocate a model-based approach to enterprise security management, in which security aspects are fully integrated in the design chain: from strategy and business model, through enterprise architecture, to the design and implementation of the organization and IT support. For this purpose, risk-related concepts are included in existing architecture and design languages. At the <a title=”enterprise architecture, Archimate” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/”>enterprise architecture</a> level, <a title=”ArchiMate open standard” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/”>ArchiMate</a>, as a broadly accepted open standard (with available tool support) that is suitable to describe business and IT aspects in an integrated way, is an obvious choice. Architectures described in <a title=”ArchiMate goals, principles and requirements” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/”>ArchiMate</a> can be linked to goals, principles and requirements, and to detailed design models expressed in languages such as BPMN or UML. The resulting models provide the input for risk and vulnerability analysis, highlighting the areas in the architecture that are most susceptible to attack. In addition, they will guide the design of effective and efficient security measures.With this approach, <a title=”Bizzdesign the Netherlands Contact” href=”http://www.bizzdesign.com/contact/netherlands/”>BiZZdesign</a> can help you to design a secure organization – without unduly restricting your people in their daily work.

Enterprise Architecture Roadmap for success: Adopting an open approach to Enterprise Architecture

January 13, 2013 by BizzDesign Staff

This is the fifth posting in our “EA Roadmap for success” series. In this posting we zoom in on the use of an Open approach to enterprise architecture. <div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Enterprise-architecture-roadmap.png” alt=”Enterprise Architecture Roadmap” title=”Enterprise Architecture Roadmap” width=”600″ height=”375″/>Enterprise Architecture Roadmap</div><h2>Frameworks and approaches?</h2>One of the key challenges of getting started with enterprise architecture (EA) is to agree on goals for the EA practice, and subsequently to find and agree on a framework / approach / method that helps the organization to realize those goals.In the early days of EA (1990’s and the early 2000’s), we saw many organizations growing their own approaches and frameworks. By working with business sponsors, architects experimented with different processes for EA, frameworks to structure EA products, modeling languages and notation and so on.While this worked well in the ‘old days’, many best practices have emerged and ultimately led to the major frameworks / approaches / methods we see today: ArchiMate, TOGAF, IAF, Zachman, DYA, and so on. Some of these are ‘general purpose’, while others (e.g. MODAF/DODAF) appear to be particularly useful in a single branch.<h2>Build or Adopt? Open or closed?</h2>While organizations in theory face a choice of ‘build or adopt’ where it comes to frameworks, we see that many chose the latter. With all the experiences and best practices that have been developed, most organizations realize that there is little point in re-inventing the wheel all over again.The question that remains, then, is this: do we adopt an open approach, or a proprietary / closed approach?This question can be answered on many different levels. One could argue that “open vs closed” doesn’t really matter, as long as the selected framework does what it is supposed to do. While this may seem true at first glance, we do believe that there is a lot to be said about principally going for an open approach. The main advantages here are as follows:<ul><li>Know what you will get: all details about open frameworks tend to be available in the public domain.</li><li>Choose your partners: because the frameworks are in the public domain, you’ll often be able to select which vendor can help you get started – if needed at all. Along the same lines: if the vendor doesn’t deliver what was requested, switching is easier.</li><li>Get involved: perhaps most importantly, if the framework is lacking in certain areas, organizations can often join and publish their own best practices, furthering the framework for all other users.</li></ul><h2>Adopt as-is, or tailor to specific needs?</h2>To conclude this posting: there is one more choice that organizations have to make when adopting a framework, be it an open or a closed/ proprietary one: should we adopt the framework as is, or tailor it to our needs? <div class=”captionImage left” style=”width: 348px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-architecture-framework.png” alt=”Enterprise Architecture Framework” title=”Enterprise Architecture Framework” width=”348″ height=”400″/>Enterprise Architecture Framework</div>The best practice here is simple: pick and choose! Most approaches explicitly recommend users to tailor the framework to organizational needs. In TOGAF this is being done as part of the preliminary phase. While TOGAF recommends that certain parts not to be skipped, it is of course entirely up to the individual organization to decide what is useful and what is not!<h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers project based implementation of EA. It is scheduled to be posted on January 29.

Lean or Six Sigma?

January 8, 2013 by BizzDesign Staff

<a title=”Lean Management” href=”http://www.bizzdesign.com/consultancy/lean-management/” target=”_blank”>Lean Management</a> (Lean) and Six Sigma are getting more and more popular. These methods were developed in the industry, but have proven to be very powerful for service organizations as well. They use the approaches and instruments to systematically work on process and quality improvement. With the large challenges many service organizations face (cost cuts, quality issues, increasing customer demands) these improvements are more than welcome. But which method is best?Like always, this depends… Both methods have their advantages and disadvantages. Let’s take a look at the methods from an ‘instrumental’ point of view.<div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/lean-six-sigma-what-is-best.jpg” alt=”lean six sigma” title=”lean six sigma” width=”600″ height=”400″/>lean six sigma</div>An important strength of Lean is the fast implementation. Lean aims at standard solutions to standard problems. Lean is focused at customer value and waste. By applying Lean best practices organizations can quickly streamline their processes and remove waste. Quick results can work as a catalyst for further Lean implementations and Lean successes. But what if your problems are no standard problems? In this case Lean won’t (completely) resolve them. You might need ‘something stronger’.Six Sigma is a method for analyzing and resolving complex problems. Based on measured facts a dedicated improvement team will use powerful (statistical) techniques to really understand the specific problems. Symptoms, problems and causes are identified, enabling the team to fundamentally improve processes. But Six Sigma comes at a cost. Setting up the program and training the team members is expensive. Also, the method achieves improvements by resolving ‘problem by problem’. With a typical Six Sigma project taking about three months, it will take a lot of time (and costs) to come to a big impact for the organization.So both Lean and Six Sigma are powerful. It all depends on the problems you have and the fit of the techniques with your organization. If we look at service organizations, we usually see lots of opportunities for improvement. They all face challenges like customer focus, quality and processing speed. Lean offers easy to use, common sense techniques to tackle these issues. Six Sigma is powerful as well, but for many organizations a bridge too far. The complexity of the method could draw away the attention from what it should be all about: improving processes and achieving results. Many organizations that experimented with Lean and Sigma also came to this conclusion: initially remove waste and streamline processes with lean; secondly use Six Sigma for specific complex problems.Besides the instrumental viewpoint on Lean (and Six Sigma) there is also a cultural viewpoint that might be even more important. Organizations that are successful in systematically improving processes don’t only use the techniques, but they ‘live them’. There is a drive to ‘do the work every day a little bit better’. Lean becomes part of the culture.Good luck with Lean and Six Sigma in your organization!

EA Roadmap for success: the Architecture Board

December 23, 2012 by BizzDesign Staff

This is the fourth posting in our “EA Roadmap for success” series. In this posting we zoom in on the Architecture Board and its role in making enterprise architecture a success within organizations.<h2/><h2><div class=”captionImage left” style=”width: 337px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Role-of-the-architecture-board.png” alt=”Role of the Architecture Board” title=”Role of the Architecture Board” width=”337″ height=”221″/>Role of the Architecture Board</div></h2><h2>Architects show up everywhere</h2>One of the things we stumble across in many organizations is that some people see ‘architect’ as a job title rather than a strategic discipline. The line of reasoning being something along the lines of “first you’re a designer / engineer / …, then you’re a really good senior designer / engineer / …, so if you progress from there, well, I guess that makes you an architect”. While there’s something to be said for senior staff to grow further, there is a real danger in calling them architect.A key aspect of enterprise architecture work, is the holistic approach in which different perspectives on some system (business, it, or the enterprise at large) are unified and considered as a whole. Being an expert in one role, does not guarantee that one has the ability to “see the other perspective” as well, which may result in architects coming from different disciplines bickering about direction and solutions which eventually leads to high cost, low value add, low efficiency and a poor reputation.An important task of the architecture board (AB) is to prevent this from happening. In the words of the TOGAF standard:“This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.”Typical responsibilities of the AB are:<ul><li>Establish an effective architecture team</li><li>Defining and maintaining consistency of architectures and sub-architectures, also across changing requirements with respect to the architecture</li><li>Enforce architecture compliance</li><li>Ensuring that the discipline of architecture-based development is adopted</li><li>Resolving ambiguities, issues, or conflicts that have been escalated</li><li>Providing advice, guidance, and information about the architecture</li></ul>These tasks get a different meaning, depending on the role of the EA-function in the organization. Below we will outline the main difference between the role of the AB in a top-down versus a bottom-up approach.<h2>Role of the AB in a top-down approach</h2>As we’ve seen in previous posts of this series, the main goals for EA in a top-down approach are to align with the strategic level of the organization. At first sight this implies that EA is about the implementation of strategic change. However, it should be noted that there is also the aspect of driving strategic change based on knowledge about the architecture of the enterprise.In such approach, the main goal of the EA discipline is to be the linking pin between strategy and implementation: define projects and programs and make sure they deliver capabilities that help realize a chosen strategy. Of course, as we also have seen in the “embedding” post, the AB cannot do this in isolation, and has to cooperate with e.g. project management and delivery to make things happen. Governance plays a crucial role in such approach. On the one hand the AB defines and approves projects. On the other, it works with other governance bodies (ie., security governance, data governance, etc.) at “lower levels” in the organizations, aligning their efforts and giving final approval / discharge when projects are done.In that sense, the AB also has the responsibility to be an enabler: projects need resources (rooms, staff, machines, money etc.) to do their work effectively. If the organization wants to achieve certain results, and the AB is tasked with making this happen, then they should also have the power to make sure that projects obtain these resources. Since resources tend to be scarce, this usually results in a balancing act, working on priorities and risks, and closely cooperate with the project management office.Last but not least, it should be noted that change does not happen overnight and is frequently met with resistance in the organization. The AB plays an important role in communication, building trust and commitment around certain (strategic) initiatives and the resulting change.<h2>Role of the AB in a bottom-up approach</h2>The role of the AB in a bottom-up approach to EA is somewhat similar, but with different accents. In a bottom-up approach, the focus of EA is on resolving operational issues, and assisting projects with sound architectural advice.In this case, the role of the AB can also be seen as “enabler”: making sure that operational issues are prioritized, that resources are allocated accordingly, and bringing together different perspectives on these operational issues in order to resolve them as effectively as possible. We frequently see that the AB is populated with (upper) management in order to make sure that decisions can be made, that the right staff is brought together in mini-projects to tackle important issues head on. This avoids the bureaucratic hassle as well as “not invented here” syndromes.<h2>Board structure</h2>To conclude this posting we dive into the board structure. This part is inspired by the TOGAF 9.1 standard as well as several engagements with clients over the last few years.First of all, key to success is to get the right people on board. In both a top-down and a bottom-up approach, we typically see a mix of (senior / upper) management and lead architects for different ‘domains’ (which in this context may either mean ‘field of expertise’ such as data or security, or it may mean a line of business). A management assistant to take notes, log action items etcetera tends to be indispensable as well.This brings us to the second issue: key to success is transparency. Everything the AB does, and particularly every decision that is made should be documented and made available for the entire organization. This greatly improves trust and visibility, which is key to getting results. Typical items for publication are:<ul><li>A manifesto that describes the role and responsibilities for the AB</li><li>Agenda of upcoming meetings </li><li>Minutes of all AB-meetings</li><li>Links to architecture regulations such as strategies, policies, principles and standards</li><li>Compliance assessments and Governance log </li><li>Open and past action items</li><li>Etcetera</li></ul>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers open approaches for EA. It is scheduled to be posted on the 8th of january 2013.

Paralyzed by Cloud? Keep up planning and supporting your organization!

December 17, 2012 by BizzDesign Staff

Day by day, while the hype is fading away a bit, ‘Cloud’ is getting more real. Every day, new Cloud services emerge. Many suppliers of traditional IT-services transform their offerings into services that can be experienced as true Cloud-services: charged on a pay-per-use basis, provided with elastic capacity and configured by means of customer self-service mechanisms. And of course every now and then new Cloud suppliers enter the market with new, sometimes brilliant offerings both in its simplicity and functionality. Like WeTransfer.com, that offers exactly the solution everyone was waiting for: Sending over huge files with a few clicks, getting rid of large e-mail attachments or inconvenient file sharing solutions. The range of Cloud offerings gets more varied every day, making it a phenomenon to stay.<div class=”captionImage left” style=”width: 350px;”><div class=”captionImage center” style=”width: 350px;”><img class=”center” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Cloud-difficulties.jpg” alt=”Cloud difficulties” title=”Cloud difficulties” width=”350″ height=”233″/></div></div> However, to be able to make good use of Cloud solutions, organizations that use this solutions need to adapt to Cloud. End-users should experience their digital workspace as transparent and consistent, whether its parts are based on Cloud (enabled) services or not. It means, for example, that much thought needs to be spent on how to deal with authentication and authorization in regard to Cloud applications. Isn’t it tedious that you have to log on to WebEx with different credentials than you use for your Box-account, at the same time having a third set of credentials to access your Cloud-based timesheet application? Or think about the need for application messages to be adequately transferred between applications that run at various Cloud providers. Or how differences in Cloud service models can be amalgamated towards end-users. Integration is the key word, and it is far from fixed. Even more because standardization in these areas has taken its first steps, if any.It is those difficulties that seem to hold back organizations. Not only regarding the implementation and integration of Cloud solutions. Even necessary and quite basic changes are postponed, thus hindering the development of the organization itself. At this moment in the development of Cloud, it is better to resolve in a traditional way than doing nothing because no feasible Cloud solution is present yet. To be able to be productive in a 21th century organization, employees do need proper digital workspaces and corresponding applications. So, don’t push your organization to Cloud, “no matter what”. Instead, focus on IT-landscape development with a good portion of Cloud integration architecture. Decide which IT-functionality with which quality your organization needs today and asks for tomorrow. Is it possible to find a solution in the Cloud? Good, use it! Isn’t it there yet? Fine, just build it yourself. At least, start thinking about how a distributed IT-landscape will look like, and how to integrate it. Make sure you get into the position to direct the delivery of Cloud services. The key to this is focusing on functionality and quality required. Because when you know that, it is easier to plan realization. Whether you immerse yourself in Cloud or prefer/need to provide IT in the traditional way a little longer. At least that will keep you moving forward, isn’t that what really counts?

Business Requirements Management Handbook review

December 7, 2011 by BizzDesign Staff

Before even starting with an introduction about the Business Requirements Management Handbook, a short introduction about Business Requirements Management:
The demands of principals, users and other stakeholders, in other words the requirements, fo…

Logical and phyiscal component descriptions in ArchiMate

November 21, 2011 by BizzDesign Staff

In two previous postings we have discussed the necessity of separating the what of architecture from the how (see here) and concluded that it is both useful and important to distinguish between a logical, ideal-world architecture description for a so…

BiZZdesign positioned as a Leader in Gartner Magic Quadrant for Enterprise Architecture 2011

November 14, 2011 by BizzDesign Staff

Enschede, 7 November 2011 – BiZZdesign, a leading provider of Enterprise Architecture solutions, today announced that it has been positioned by Gartner, Inc.* as a Leader in the Gartner Magic Quadrant 2011 for Enterprise Architecture**. This Magic …

Component descriptions in ArchiMate

November 7, 2011 by BizzDesign Staff

In a previous post we discussed two levels of architecture description within ArchiMate: the service level describes the what and the underlying components and processes describe the how. The motivation for making this distinction was also discussed:…