Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
As you may have read on my blog or even when you hear me present, I talk about how crucial soft-skills are to Enterprise Architects. In my personal opinion I think the majority of our success hinges on our ability to leverage these skills.Â So when I run across resources I want to make sure I share them with all of you.
While I havenâ€™t sat in on this particular webinar, I do agree with the themes and messages this is built upon. I believe this derives from a training course called, â€śElevating Enterprise Architectureâ€ť which serves as a guide to hone in on those soft-skills or in more scientific terms, EQ. I did a full review of this course that you should check out to get a better idea on the foundations in which this webinar is built: http://www.mikethearchitect.com/2013/01/review-elevating-enterprise-architecture.html
I would highly recommend all architects check this out.Â Webinar Overview: 10 Sure-Fire Tips for Getting Stakeholder Buy-In to your Architecture Projects
For the best part of the last three-years Keith Flanagan has been helping architects across all of the domains and industries develop relationships with their stakeholders. A good architect/sponsor-relationship is the first step to success. After all, would you risk your professional reputation by endorsing an IT or architecture project if you didnâ€™t trust the people that were proposing it?
Date: 19 Nov, 2013
Time: 15.30 GMT, 10:30 EST, 16:30 CET
Webinar Registration: Click Here
Last week , The Open Group kicked off their signature Enterprise Architecture Conference in London. Like others in theÂ recent past the Open Group has taken on a industry focus for these quarterly conferences. The goal here is to provide a very tailored experience to EAâ€™s in those specific industries. With this focus and where the conference was hosted I was surprised to see the very broad attendance and representation from many nations all over the world that include 28 nations: UK, US, Columbia, Philippines, Australia, Japan, Netherlands, Germany, South Africa and many others.
The theme of this conference was Business Transformation in Finance, Government and Healthcare. There were some very interesting sessions specifically from the keynote presenters based in the UK. If you were not there you can watch the live stream of the keynote presentations here:
You will find from all of these presentations that there is a shift in how EA is used and the results generated. As an example, Judith Jones from Architecting-The-Enterprise, shared her findings from the World Economic Forum, posing the question â€śwhat keeps 1000 global leaders awake at nightâ€ť? There were stats were presented with over 50 global risks â€“ economical, societal, environmental, geopolitical and technological. There wasnâ€™t the typical drudging over IT oriented topics. Luckily this was a shared theme across many of the pure vertical tracks.
The Open Group has posted two summaries are well, I would suggest taking a look at them. I wasnâ€™t going to duplicate much of what they covered since they did such a good job. See below:
Even though there was a vertical focus the Open Group did cover additional areas around the profession of EA, forward looking views on the industry and architecture topics like big data and cloud.
Included in that were a series of announcements:
Mike Walkerâ€™s Participation at the Event
Unfortunately for myself I wasnâ€™t able to attend many of the afternoon sessions at the conference. Would see more coverage and thoughts about the event. This was due largely to my leadership duties at the Open Group in developing the next version of TOGAF.Â Specifically I spent time in two areas, leading the Business Architecture work stream along with Enterprise Architecture Capabilities workshop (see more here). I will talk more about the Enterprise Architecture Capabilities in another post.
The time that I did spend in the conference center was spent presenting to the conference attendees. I had two sessions that centered around the profession itself:
Enterprise Architecture Certifications Distilled
In my presentation, I distilled a wide range of the certifications directly applicable to Enterprise Architecture. While this was a narrow view on the EA profession, itâ€™s one of the most common questions I get from customers.Â Certifications are only one component of a career planning conversation. Most importantly for organizations, it is a component of a competency driven strategy to drive results for your organization.
With that said, and if you agree with the assertion, there are so many different EA certifications out there, without the proper framing it can get a bit confusing. I provide perspectives on certifications like TOGAFÂ®, Open CA, and Open CITSÂ to name a few. Then discuss why it is important to choose the right certification for your career. I examine why skills and experience-based certifications are becoming increasingly more important to both employers and employees as part of the professional development process.
You can see the Live Stream below for those that wasnâ€™t able to attend:
Looking into the Future Panel
Thanks to David Daniel â€Ź@AgileEngineer for snapping a shot of all of us.
In this panel session I participated we discussed some of the key issues facing the future development of the Enterprise Architecture discipline. You might of seen me talk on other panels about this very topic. A detailed post on my predictions can be found in the post entitled, â€śPredictions: Enterprise Architecture In 2020â€ť. My thoughts on these topics havenâ€™t changed much.
The questions asked were:
I wanted to extend a big thank you to both The Open Group for asking me to come and speak again at their conference along with all the attendees that joined my sessions, asked some really great questions and tweeted some of my thoughts.
On Monday November 18th I will be giving the keynote presentation at the HP Customer Forum in Cincinnati. The theme of the event is the future of IT and what you need to prepare for it. HP calls this the â€śNew Style of ITâ€ť.
Included in this event are customers sharing their stories on how to prepare for these IT trends. It should make for a great event and looking forward to meeting up with the local Cincinnati thought leaders.
For those that are local there are still a few limited tickets. If you would like to attend please let me know and will see if I can get you a ticket.
Today The Open Group released the updated whitepaper, Integrating the TOGAFÂ® Standard with the BIAN Service Landscape. This release might be beneficial for those architects in the banking space that use or considering to use TOGAF in conjunction with BIAN.
For those not familiar with BIAN, it is a not-for-profit organization which seeks to accelerate the adoption of Service-Oriented Architecture (SOA) in the banking industry. It does so by promoting convergence
towards a common service landscape, and by providing semantic standards which makes it
easier and more cost-effective to integrate such services.
This whitepaper aims to support Enterprise Architects within the banking industry, reaping the synergies of two complementary industry frameworks:
In the heart of the White Paper, both the TOGAF standard and BIAN are mapped to each other. The leverage of the BIAN deliverables in the context of the TOGAF Architecture Development Method (ADM) is further elaborated. For each step in an architecture development process, the integration of BIAN deliverables is described.
For more information
Last week was Gartnerâ€™s marquee event for its customers, Symposium ITxpo 2013. Gartner Symposium/ITxpo brings CIOs and senior IT executives together under one roof, the event offers 500+ analyst sessions, workshops, roundtables and mastermind keynotes across five full days. With 10 role-based tracks and 11 industry tracks, the agenda targets your specific title responsibilities and ways to adapt new ideas and strategy to your industry, along with insight on what's next in IT.
I wanted to provide a recap on the event based on my perspectives. I hope this is helpful to the folks that attended and for those that could did not.
My Top Five Take-Aways from the Event
For Enterprise Architects and other strategic roles I distilled the following observations from the conference.
#1 Be Prepared For The 2014 Top 10 Trends
Gartner highlighted the top ten technologies and trends that will be strategic for most organizations in 2014. Strategic technology is defined as one with the potential for significant impact on the enterprise in the next three years. Factors that denote significant impact include a high potential for disruption to IT or the business, the need for a major dollar investment, or the risk of being late to adopt.
â€śThe new technologies will help drive IT spending to $3.8 trillion in 2014, a 3.6% percent increase from this yearâ€ť
The projected increase in IT spending isn't necessarily good news for established IT vendors. Approximately two-thirds of the respondents to Gartner's CIO survey said they expect to change primary suppliers by 2017. [See more below in #2 Customers Demand New Vendor Model]
A strategic technology may be an existing technology that has matured and/or become suitable for a wider range of uses. It may also be an emerging technology that offers an opportunity for strategic business advantage for early adopters or with potential for significant market disruption in the next five years. These technologies impact the organization's long-term plans, programs and initiatives.
The top ten strategic technology trends for 2014 include:
Gartner defines a strategic technology as one with the potential for significant impact on the enterprise in the next three years. Factors that denote significant impact include a high potential for disruption to IT or the business, the need for a major dollar investment, or the risk of being late to adopt.
#2 Customers Demand a New Vendor Model
According to a Gartner, 1300 CIOs say that their vendors and partners of the future (digital IT partners) will not be the same as the current traditional partners.
Below is the predictions from Gartner on who will be the relevant technology leaders in the next 10 years.
â€śCIOs see Google as "more innovative than current enterprise vendors"
This analysis further showed that the customers over the next 5 to 10 years will be less inclined to go with a single sourcers of technology but rather diversify to many smaller more agile and innovative technology partners.
Should the big vendors be concerned? If Gartnerâ€™s analysis is correct, yes. I suspect what this means is that companies now have more options to go with smaller more agile and nimble vendors. An example of this is Salesforce.com or Workday which I think companies like these have pioneered this behavior with a combination of their go to market strategies and availability of technology.Â
#3 The Focus is on Cloud, Mobile Social and Information
The Gartner Nexus of Forces on the IT industry is in full effect. To be relevant in the marketplace today and tomorrow an emphasis on these areas is paramount. Talking with customers at the conference certainly reflected this.Â
This is reflected not only in the Gartner research but also in independent research. Shown below is the latest 2013 IBM C-Suite Infographic that shows the importance and the demand.
Just like previous events the analysts at Gartner painted a transformational view on what the IT industry was going to evolve to over the next 5 or so years. Some of the key insights that the Gartner analysts provided were included:
While each one of these insights provide their own value standing alone,Â all of these insights are connected and highly predicated on cloud as the backbone. Cloud not only provides the connective tissue but it also provides an architecture that can support the overwhelming amount of information that will open up these new business opportunities.
There is still quite a bit of confusion around what cloud really is and isnâ€™t. Daryl Plummer provides a concise view of what cloud really is in the Network World article, â€śGartner: The cloud according to Darylâ€ť
#4 There is no Private or Public Cloud, Just Hybrid Cloud
According to Gartner, 70% of companies will be pursuing hybrid cloud strategy by 2015. That might not be a surprise to some as with most solutions they were hybrid in nature before the advent of cloud when there was client / server or SOA.
What that means is that workloads will be distributed based on how technology decision where made in the past (i.e., heavy focus on infrastructure and apps) but move toward a business oriented IT organization focused on business capability and information.
Focusing only on one service model (IaaS, PaaS or SaaS) or delivery model (Private, Public, Hybrid or Community) is flawed. The go to market strategy must have a cloud playbook that allows for the combination of these to come up with the right solution based on three levels of detail:
You can find more of more of my specific insights on this topic in the posts referenced below:
#5 IT Grows Up. Focusing on Strategic Business Value.
The IT world is shifting dramatically, more so than it ever has. Not only as seen in technology but also in itâ€™s operating and organizational models. IT is moving from a classic run or operate IT to be better aligned with the business to deliver innovation that drives strategic value.
Below you will find how the head of IT, the CIO is evolving to support these demands.
â€śCIOs that don't adapt will become simple custodians of back-end systems. Companies that fail to change will join Kodak, Blackberry and Wang, each of which was slow to recognize new forces in technology.â€ť
You can find more of more of my specific insights on this topic in the posts referenced below:
Like every year, Gartner has released yet another great resource for Enterprise Architects with their EA Tools Magic Quadrant. This is a very useful tool especially if you are in the market for an Enterepise Architecture tool. Gartner dog a good job of plotting holistically where each player in this complex space resides based on their criteria.
Enterprise Architcture 2013 Magic Quadrant
Below you will find the Gartner Magic Quadrant. If you have seen years past the format and even the players will be familiar. However, play close attention as the players have shifted somewhat.
Gartner bases this analysis based on the following criteria:
According to Gartner's Julie Short, "The overall market is improving its strategy to deliver business outcomes, as demonstrated by the many inquiries Gartner receives from clients on this topic."
If you have seen last years past MQ analysis you can find it here: http://www.mikethearchitect.com/2012/11/gartner-enterprise-architecture-tools-magic-quadrant-2012.html
What you will notice is that this space is starting to solidify more. Int he MQ shown below you will see Avery crowded "visionary" quadrant. This year there acre some clear differences.
Overall the 2013 MQ looks a bit more refined and clearer on the differences in the Enterprise Architecture tool landscape. The criteria and the rational also seems a bit more susynced.
If you would like a full copy of the report, Troux is providing a complementary copy found below:
Posted with Blogsy
I wanted to share with all of you a great learning resource if you're interested and understanding theÂ Enterprise Architecture modeling notation called ArchiMate. If you follow my blog you have seen me talk about ArchiMate in the past as the â€śgo toâ€ť standard for EAâ€™s. But I have also warned EAâ€™s about taking these notations too far with my latest post entitled, â€śDonâ€™t Get Caught Up In The Architecture Modeling Debateâ€ť.
I would like to provide you with a link to a book that I think is worth while looking at. Itâ€™s called, Delivering enterprise architecture with TOGAF and ArchiMate.Â
Full disclosure, I did an early review of the book and wrote the forward for it.
However, I believe the book was written by the authority for ArchiMate, the Chair of the ArchiMate forum within the Open Group. Based on that and other facts I feel very comfortable endorsing this book.
Personally, I believe ArchiMate is extremely well-suited for enterprise architects and their modeling needs. It provides the right level of semantics for engaging at the level of abstraction that enterprise architects typically work at. But again, this is a tool used by and for EAâ€™s not all stakeholders.
This book will help you in these two primary ways:
Below is a link to the book and some other supplemental resources.
Slideshare PresentationDelivering enterprise architecture from Bas van Gils
Business Architecture is a burning hot topic these days. I believe it is a key enabler to get us to a more contemporary or new world of Enterprise Architecture (EA). Continuing the shift from an IT centric Enterprise Architecture to a business oriented one. We not only see the evidence by the water cooler but also in the broader community. In the latest Gartner Enterprise Architecture Hype Cycle they classified Business Architecture at nearing the â€śPeak of Inflated Expectationsâ€ť. The stated evidenced provided showed:
Gartner's Symposium/ITxpo conference (Orlando 2012) saw more than 2,000 people attend Gartner's presentation, "Business Architecture: Uniting Business and IT."
A Gartner webinar (April 2013) hosted over 430 attendees.
Since early 2012, Gartner's EA research team has taken more than 180 client inquiries from clients pursuing business architecture as part of their overall EA efforts.
This is just Gartner. Other analyst firms such as Forrester has built a flurry of content around Business Architecture as well over the past two years with playbooks, articles and blogs.
I would assert that Business Architecture is the catalyst for the next wave of evolution of Enterprise Architecture. If thatâ€™s so, what is it? I will attempt to define it or at least tell you how Iâ€™ve been defining it for the past few years.
Business Architecture, An Industry PerspectiveÂ
Like with most things I go to define, it has often been defined before. Business Architecture is no exception here.Â I not only did this with how Iâ€™ve defined Business Architecture before but also wanted to pull from an updated definitions from around the industry.
While there are quite a few Business Architecture definitions out there, I pulled only the ones that were coming from either influential or credible sources. These few definitions from analyst firms and standards bodies should give you some contrast into what some of these leading organizations define Business Architecture:
Each one of these definitions have very good qualities and resonate on their own. However, the challenge I have personally is that I donâ€™t think they are inclusive enough for what I see and teach in the market place. The reason I say this is for the following reasons:
A Definition for Business Architecture
For me, I have a very specific Business Architecture frame of reference for what I believe business architecture is based on. This is through my experience working with customers that have leading Business Architecture practices, my personal experience building out Enterprise Architecture practicesÂ and the workshops in which I teach EAâ€™s about Business Architecture.
In my post, â€śAustralian And New Zealand Architects Surveyed On Business Architectureâ€ť, I talk about how Business Architecture boils down to rationalizing the "Why" part of the question into a set of usable things that we can execute on. For me itâ€™s that simple.
The definition I have been using for some time now with customers is the following:
A formal method and a set of descriptions that distill the business environment and the needs of a business into set of models representing business information, concepts, value and risk that are expressed through an architectural view of a business.
With this definition I wanted to be inclusive of all aspects of business architecture. I found most descriptions or definitions are too narrow or prescribe a particular outcome. I believe that business architecture is a means to an end not the entire solution all unto itself.Â Business Architecture is a critical part of Enterprise Architecture, ensuring all of the EA oriented in a way to maximize value.
As you may of noticed, I have highlighted certain words. For the rest of this post I will go through the highlighted words in the definition in an attempt to explain each on independently to show how they relate and describe Business Architecture.
So lets start decomposing the the definition.
#1. Operates within Enterprise Architecture [Implied]
While not stated in the actual definition, it is implied that business architecture is a domain within Enterprise Architecture.Â Â
Business Architecture on itâ€™s own only provides a small subset of a complete solution. For example, only understanding a business model doesnâ€™t get your stakeholders any closer to defining a solution to a problem or opportunity. Itâ€™s when you bring in the macro level EA methods combined with the other domains of architecture where you really see the power behind business architecture.
From an industry perspective, there is a tendency to try to make business architecture an independent framework.
This approach is very dangerous.
There are many motivations for this, some I believe are the right motivations but the implementation in my honest opinion are very wrong. I think so of this stems from a misunderstanding of the intent of Enterprise Architecture. The challenge comes in when we mix the current state environment in which some organization implement EA or lack there of and the definition of EA from the EA standards community.
As an example, I was digging through my personal archives of content and found a TOGAF 7.0 overview deck from the Open Group. I was surprise to see, even then a business outcome focus from the EA community. Note however, there was not a whole lot of guidance around this until 9.0 but the intent and direction was clearly stated from the very early days of the TOGAF standard.
This topic can go on for awhile and most certainly warrants more decomposition of the current state, so keep us on point here I will be writing more about this in another post.
#2. A Formal Method
With most definitions that I harvested over the years, I see business architecture as a thing you produce. If we examine both the Gartner and Forrester definitions, theyÂ call it out as a very specific set of approaches to Business Architecture.
IBM also states it really well with this explanation in an IBM whitepaper entitled, â€śActionable Business Architecture: An IBM Approachâ€ť:
[Business Architecture] Methods are techniques that weave through the various contexts using proven methodsâ€¦ [Business Architecture] Methods should also describe the how-to of execution while enabling further integration into an Enterprise Architecture (EA) context method.
I believe that Business Architecture isnâ€™t a deliverable but rather a discipline within Enterprise Architecture that has a set of methods, roles and artifacts that serve to solve a very specific part of a problem. Arguably the most important aspect, the context into why we are doing an activity along with ensuring what is delivered ultimately provides the most benefit back to the company.
The challenge I have with some interpretations of Business Architecture is that it is either implied or explicitly defined that a specific artifact is the results of Business Architecture. The OMG definition is a good example of this with stating, â€ťblueprint of the enterpriseâ€ť.
The problem with this is that this is really meaningless with out some purpose. To what end does this blueprint serve. You could also replace that with business capability model and have the same questions. What I sometimes find and advise against to my clients, EAâ€™s should not pivot there work off a specific artifact or deliverable. Focus on the outcome you wish to achieve and work through a proven method to generate a consistent result solving that problem.
Without a method you will find yourself generating artifacts for artifact sake, while sometimes we get lucky, we know that hasnâ€™t yielded effective results.Â
#3 Distilling a Business
As mentioned above, a big component of business architecture is to distill and rationalize a business. What does this mean? Simply put, letâ€™s understand what the business wants by putting their needs and wants into a set of constructs that us as architects can understand and facilitate the decision making process.
While this is a simple concept, it is very important tone setting statement. Business Architecture does not create business strategy but rather it serves to understand it. There is a very clear divide in the industry here. I believe it is the case here based on the evidence I see in the industry along with other thought leaders in this space. Here is why I donâ€™t think Business ArchitectureÂ
Is there a role for Business Architecture in creation of strategy? Yes. But it should be leveraged as a tool to enrich the basis for the corporate or business unit strategy not as the defining method.
So lets take a look at what two primary aspects are distilled.
#3a Business Environment
This aspect is one in which that is easily overlooked because it can be seem that it so far away from solving the actual problem. Sometimes it is but more times than not this aspect is vital to making the right decisions.Â
Here we are looking at the surrounding business environment of the problem that is to be solved with Business Architecture. Meaning everything around the company which can include an inwards view but mostly an outwardly view.
This can includes but not limited to the analysis of:
The list of areas to include in understanding a business environment are vital to how we as Enterprise Architects build our solutions. You maybe asking why these are so important. Or maybe you are wounding why are things like pandemic or natural disaster included here. Let me give you an example.
Lets rewind to Katrina in 2005 and look at the challenges from the banking industry. When this horrible disaster hit, banking locations were closed for weeks. If you were a small bank you might have your entire business and IT environments in the impacted area. Understanding these conditions are important so that you can plan accordingly. Meaning you architect for these considerations.
This was one small example, but for global organizations operating in many different countries with different considerations we can understand those to provide an optimal solution for our businesses.
#3b Needs of a Business
This one is fairly broad but meant to be. Often times you see Business Architecture defined as taking in strategyÂ and doing something with it. While I think this is certainly one use case but I donâ€™t think it is the only one.
The reason for simply saying â€śneeds of the businessâ€ť is to be purposefully that broad. It shouldnâ€™t matter what comes into the Enterprise Architecture process, all of it should be understood from a business perspective.Â Even if that thing is a great new technology trend like wearable technologies. We would still want to understand the business implications and opportunities it presents to a business regardless if it comes through the technology architecture domain.
In this definition â€śneeds of the businessâ€ť is a way to define what ever the business wants. We donâ€™t want to be prescriptive here as it would lead us down one specific path. These needs are usually through one or more of the following:
#4 Business Information
Lets take a small step back and understand what we mean by information. I donâ€™t mean data.Â Data is context-less raw facts about things, while information is much broader and has an important element, meaning. You can see a visual this represented in the visual from Barry Ritholtzâ€™s blog post entitled, â€śIntelligence Hierarchy: Data, Information, Knowledge, Wisdomâ€ť. Keep in mind this post wasnâ€™t from the vantage point of an EA but nevertheless he does a good job articulating the difference between data and information.Â
A growing trend in todayâ€™s economy is that goods and services are starting to serve as an end to the real currency, which is information and/or intellectual property. From a business architecture perspective information is a key element of understanding where the business was and wants to be.Â
Below is an example of some of the ways information provides a meaningful Business Architecture:
#5 Business concepts
The term used here is another broad but purposely broad term. It is meant to encompass all the business concepts we want to articulate for our business architecture. There are quite a few of them so the rational for using business concepts rather than naming 20 different business â€śthingsâ€ť was to not be prescriptive. Also I am sure there would be some left as well.
So here we want to identify a category of business oriented concepts that would involve modeling all the different aspects of a business. This could include but limited to the following:
By examining these aspects along with their relationships we can understand the needs of a business better along with creating a model for realizing value.
#6 Business Value
Enterprise Architecture is a methodology that is business value driven. Business Architecture as a key domain within it inherits this position as well. An outcome of this and any architectural process should be defined and a model for maximizing value for a business. Business Architecture is square in the middle of taking a business case that was (or wasnâ€™t) defined and ensuring it can be quantified and qualified.
In Business Architecture we identify, define and quantify value that will serve as the basis for all other architectural work.
Through leveraging value and benefits management techniques we can properly. This is much like a traditional financial analysis that would include the valuation of existing investments and the forecasting of new opportunities. Through this process itâ€™s important to use models that either resonate with your business or are common in the financial industry.
Examples of value models include:
Those models will help you understand a broader value picture. Additional models that can be used as inputs into these are:
Business Architecture not only models value but also determines how value can be maximized. This is one of the benefits that Enterprise Architecture can deliver. It can identify new opportunities not seen before by business stakeholders.
#7 Business Risk
We just looked at value and understanding benefits but there was one aspect not covered within it, risk. Understanding value has two facets, benefit and risk. Understanding risk within Business ArchitectureÂ allows us to do the following:
Through the usage of risk management techniques within Business Architecture we will be able to identify, assess, and prioritize business risk to ensure that risk is well understood and managed throughout the architecting process.
Through this quantification we should use standard risk methods such as:
#8 An architectural view of the business
This aspect of the definition addresses another key debate in the industry. It is perhaps the most important mental framing concepts of the definition. I often hear Business Architecture described in one of two ways.
Based on the rest of this post you can see where we are going here. In my definition of Business Architecture we are looking at a business need through the lens of an architect. This means that we create models that we can use through the architecting process. They are not:
With this said, Business Architecture should be presentable to business unit leaders (as with most architecture artifacts) which the artifacts and models created should lend from the business world primarily but not at the expense of architecting.
I hope this definition of Business Architecture has been helpful or enlightening. However, given the wide variety of definitions in the industry I am afraid not everyone will agree. I hope to hear from you on whether this definition of Business Architecture resonates or not.Â
At the Open Group Conference in London I will be leading two very impactful work streams for the practice of Enterprise Architecture. The first is an Enterprise Architecture Capability Model. This model takes the concept of a capability and applies it to the outcomes you want to achieve from Enterprise Architecture. If done right, this will be a huge productivity gain for enterprise architects.
The second is another highly highly impactful area of Enterprise Architecture, Business Architecture. If your an Open Group member and have a passion for advancing Business Architecture please join the group of high caliber architects to advance this area of EA.
Below you find a more through overview and scheduling details for just the EA Capability session. To attend the Business Architecture work stream you must be a TOG member. If you want to talk to me personally at the conference or otherwise please leave a note in the comments.
Details for the Enterprise Architecture Capability Sessions
Attendees of the Open Group London conference are welcome to join the Open Groupâ€™s EA Best Practice Development Workshop on Wednesday Oct 23 9:30-12:30. In the workshop, we will explore best practice and benchmarking based assessment of enterprise architecture management and process maturity. Our purpose is to enable organizations to identify and execute improvements that deliver real business value.You might of seen some of my EA Capability work before, if not below are some links that might be helpful. Within the Open Group the view on the work will take a similar approach.
During the workshop an EA Capability Model, Assessment and Best Practice framework will be presented. As a participant you are expected to ask questions, make comments and influence the development of the framework. Your experience, expectations and requirements will through a series of round table discussion sessions.
In developing this best practice and benchmarking it is very important that the Architecture Forum understand the views of Open Group customer organizations that do Enterprise Architecture in-house, as well as experts in the field.
This workshop has very limited space and requires a reservation. To attend you must be registered at the Open Group conference and have a workshop reservation. To obtain a reservation please contact Raina Wissing (firstname.lastname@example.org)
Communicating your ideas and architecture work effectively can be really tough. When we do we using create compelling visuals or models to communicate the complexities of our work. When I talk to architects I find there are many out there that really struggle with getting their messages across to their customers. They also feel that sometimes their communication is just out of their control or the audience just doesnâ€™t get it. Meaning, they should get it, what were they thinking, right?
But is it really there fault? Maybe, maybe not.Â
The genesis of this post came from a series of recent conversations. I wasnâ€™t sure if I wanted to create this post or not given the topic but in the past two weeks I have wither run into scenarios or have been asked specifically about this topic. The questions were all different but all led to the same basic theme. These questions included:
For as long as I have been in IT I have seen this. The same debates but with different names continue on. For those that have either worked for me or know me I have had the same answer for some time now. But lets wait on that door a momentâ€¦
Itâ€™s a funny adaption to a very real situation. I often find my self in a modern day Capulet vs. Montague battle between which is the better way to describe the things we architect.
â€śWhat's in a model? That which we call a Business Capability Model,
By any other name would it be as effective to describe our businessâ€ť
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - adapted from Act II, Scene II of Romeo and Juliet
There are a couple aspects to this scenario. The first is the tooling. I usually see three camps here. The EA tool folks that use it for modeling, the Visio folks and the PowerPoint folks. Then comes the real holy war, the actual notation. Some say itâ€™s UML, some believe itâ€™s ArchiMate while others just stick to their homegrown methods.
While sometimes interesting to watch, it can be frustrating to watch the debate. What it ultimately boils down to is, while we are having debates about which tool and notation the following isnâ€™t getting done:
I think we lost our perspective on why we create these rich visuals, models or diagrams. These serve two primary purposes in my mind:
You might say, well Mike, you forgot about all the rich things you can do in the modeling notions that can link aspects of your architecture together in a very qualitative way. I agree these are important and sometimes be game changing if you are at a level of maturity to support it. However, if the two primary aspects are not covered, what you modeled is shelf-ware. If your stakeholders who are paying for your effort canâ€™t buy-into your architecture just for the simple fact that they canâ€™t get their heads wrapped around our world of architecture, we have failed as architects.
A model being used as a communication tool, is the most important aspect in my opinion. This isnâ€™t just my opinion but that of the architectural standard for describing architecture, ISO/IEC/IEEE 42010:2011 or formally known as IEEE 1471. In this standard, there is a core problem we are solving (i.e., Mission) with a set of stakeholders that have concerns that need to be addressed. Those concerns are addressed through the architecture models (i.e., view points, views and models).
The problem we get into is we want our models to be perfect. This may mean a high order of fidelity in the models, highly detailed or have a high level of precision. The challenge here isnâ€™t perfection but that of communication to our stakeholders that have either sponsored (i.e., paid) for our efforts and/or need to buy-off on the architecture before it sees the light of day. Like the quote about truth, â€śthe right model is in the eye of the beholderâ€ť or the Don Box quote, â€śAll models are wrong but some are usefulâ€ť.
So if we agree with the assertion that the critical component of a model is used as a communication method to stakeholders of all different varieties, then letâ€™s consider the following breakdown to not choose the one model to rule them all, but rather a set of fit-for-purpose models that apply to the appropriate audience along with the right situation.
I break the models we create as architects up into two categories and add an additional one as the supplemental repository for ad-hoc models that fit only special circumstances.
Below is a visual that describes this as well:
The reason we want to break these up this way is simple, one set of models you use to communicate directly with your stakeholders or as I labeled them consumers of the models to be a bit more generic. These people who view these models do not have the architectural skills you do nor do they understand the complexities that go into our job. More times than not, it can be determinate to try to educate on the architectural detail as they donâ€™t have the understanding or the experience to fully understand why the decisions were made.
On the other side you have models for architecture professionals. These people are very knowledgeable in the architecture space. More times than not, they are looking for detailed models with a high degree of rigor to understand the impacts the architecture may pose. I have also referred to these people as the â€śBuilder Guildâ€ť.
Why call them that? Itâ€™s simple really. Just like in other well established profession you will find that the practitioners very different when among their own professionals versus in front of their customers. A great example of this is with home builders. I have built several homes and have had the same experience. I never got a blueprint. I only received a layout with dimensions and maybe a 3D video. Outside that I wasnâ€™t provided anything else. The builder gave me as much as I needed to make a purchase decision with that model and others.
When we reflect back to the problem at hand I would strongly suggest we treat the way we communicate along with the visuals we provide just like how many other very mature professions treat it. If we do that, I think we will be much more effective in our success with our customers.
Mapping back to the structure defined you will see some interesting responses to the questions that were asked.
#1 What architecture modeling language should we use?
It just depends on who you are talking to. A consumer vs. an architecture professional. For an architect perhaps you want to use an industry standard notation like ArchiMate. However if you are talking to one or more people from across your organization like a business unit executive perhaps you want to throw out all those complexities and go straight to either existing visuals that have worked well or build less structured visuals with styles that he/she is accustom to.Â Â
#2 Should we be using ArchiMate notations instead of BPMN and UML?
If we build on the first question and assume this question is geared for an architecture or IT audience then it would be the right question to ask. Keep in mind all of these notations are tools in your virtual EA toolbox. Each one of these notations has a role and caters to a specific audience. Each one of these has a discrete audience and purpose. ArchiMate for architecture, UML geared for software development and BMPN built from UML to describe business process more effectively. My advise, donâ€™t try to use one for everything, make sure what you build is fit for the task at hand.
#3 PowerPoint isnâ€™t for architects, Visio or [EA Tool Name Here] is.Â
I heard this statement more than a few times, with some more negative in tone. My belief here is all three classes of tools are appropriate for the right situation.Â The tool that seems to get picked on the most is PowerPoint. In my own experiences or have seen / witnessed, there have been very clear successes with using a tool like PowerPoint. Remember, itâ€™s not the tool or the notation, itâ€™s the circumstances and the audience in which you are addressing.Â
So the final words of wisdom, donâ€™t get caught up in the architecture modeling debate. Itâ€™s just a model, get over it. Reverse engineer from what the expectations are from your stakeholders.
Wow, itâ€™s been 2 months since my last post. I canâ€™t believe itâ€™s been that long. Things have surely heated up this summer . Outside of spending some quality R&R with the family, I have been extremely busy in three areas:
As many of you know, I frequent EA conferences whenever I can make it happen. This summer being no exception.Â Over the past few months, Iâ€™ve talked to many of you and you have commented favorably on the content on my blog. I wanted to send a very public thank you. I am usually writing from direct experience or providing emerging thoughts based on those and itâ€™s great to hear that resonates. Given that, over the next few weeks I will post up more content based on the questions and feedback from my presentations. This will also come with some extended materials that will provide more context into my thinking around those topics. As the year is coming to a close, the last two events major event of the year I will be going to for sure will be:
One of the best parts of my job is getting out of my office and into the thick of it with practicing EAâ€™s. Iâ€™ve had an absolute blast talking with executives and EAâ€™s about their challenges and how to enrich aspects that are working really well. Not only do I get to share my experiences but I am also learning a ton as well.
Outside of collaborating with practitioners and speaking at conferences Iâ€™ve been busy with standards work. I have, â€śput my money where my mouth isâ€ť . A few months ago I posted the â€śCall to Actionâ€ť for EAâ€™s who want to make the profession better to contribute to the standard. So that is exactly what I am doing. I am taking my real world experiences and bringing it back into the standard.Â
As of the last member meeting at the Open Group conference I am directly leading or providing substantial focus and leadership in three areas:
If any of you out there has an interest in participating in these activities, please let me know via my Twitter handle @MikeJWalker. This is especially true if you are an internally facing company practicing EA. One of the key objectives of building the next wave of the standard is to ensure applicability to all of you and base on proven practices.
Sorry for the lack of â€śmeatyâ€ť EA goodness in this post, but several of you out there have asked where I had gone and thought it would be good to give all of you an update on what Iâ€™ve been up to outside of blogging.
I canâ€™t say it enough, a big thank you to all of you that have stuck with me all these years reading my ramblings on blog(s), twitter comments and listening to my presentations. I canâ€™t thank you enough.