Tag Archives: enterprise architecture

The Open Group Austin Event to Take Place July 18-21, 2016

The Open Group, the vendor-neutral IT consortium, is hosting its latest event in Austin, TX, USA July 18—21, 2016. The event, taking place at Austin’s Four Seasons Hotel, will focus on open standards, open source and how to enable Boundaryless Information Flow™.

Industry experts will explain how organizations can use openness as an advantage and how the use of both open standards and open source can help enterprises support their digital business strategies. Sessions will look at the opportunities, advantages, risks and challenges of openness within organizations.

The event features key industry speakers including:

  • Steve Nunn,  President & CEO, The Open Group
  • Dr. Ben Calloni, Fellow, Cybersecurity, Lockheed Martin Aeronautics
  • Rick Solis, IT Business Architect, ExxonMobil Global Services Co
  • Zahid Hossain, Director, IT Architecture, Nationwide
  • William Wimsatt, Oracle Business Architect, Oracle

Full details on the agenda and speakers can be found here.

The Open Business Architecture Standard (O-BA) and ArchiMate® 3.0, a new standard for Architecture, will be the focus of Monday’s keynote sessions. There will also be a significant emphasis on IT4IT™, with the Tuesday plenary and tracks looking at using and implementing the IT4IT™ Reference Architecture Version 2.0 standard.

Further topics to be covered at the event include:

  • Open Platform 3.0™ – driving Lean Digital Architecture and large scale enterprise managed cloud integration
  • ArchiMate® – New features and practical use cases

Member meetings will take place throughout the course of the three-day event as well as the next TOGAF® User Group meeting taking place on July 20.

Registration for The Open Group Austin event is open now, is available to members and non-members, and can be found here.

By The Open Group

@theopengroup #ogAUS

For media queries, please contact:

Holly Hunter
Hotwire PR
+44 207 608 4638
UKOpengroup@hotwirepr.com

1 Comment

Filed under ArchiMate, Boundaryless Information Flow™, Business Architecture, Certifications, Digital Transformation, EA, Enterprise Architecture, Internet of Things, IT4IT, Steve Nunn, The Open Group, The Open Group Austin 2016, TOGAF®, TOGAF®, Uncategorized

Digital Disruption for Enterprise Architecture

By Myles F. Suer, Chief Platform Evangelist, Informatica

Recently, I got to sit at the font of wisdom which is Jeanne Ross, and get her view into digital disruption and the role of Enterprise Architecture in enabling firms to respond. I am going to summarize her main points here which I hope will be as useful to you as it was for me.

Jeanne, Research Director and Principal Research Scientist, MIT Sloan School of Management, started her talk by saying that she has a passion for Enterprise Architecture. And she said for me and for you, as the digital economy has arrived, I have felt this was our moment. We were going to have integrated channels, seamless end-to-end transactions, real understanding of customer data, and real tight security. “And this of course means architecture”. And she in jest says that she was hoping that the whole world had come to this very same conclusion. Clearly, she said, it hasn’t happened yet but Jeanne importantly believes with the march to becoming digital, it will happen soon.

Success in the digital economy is not guaranteed

Jeanne says one thing is becoming increasingly clear–enterprises will not be successful if they are not architected to execute their firm’s business strategies. At the very same time, she has found with the companies (existing successful enterprises) that she talks to believe their success is not guaranteed in the digital economy. Given this, Jeanne decided to research what incumbent enterprises actually look like that have taken concrete steps to respond to the digital economy’s mandates. The 27 companies :

  • The challenges they are facing
  • The disruptions that they had identified
  • The strategies they were moving forward with
  • The changes that they had already put in place

She found that digital strategies were inspired by the capabilities of powerful readily available technologies including things like social, mobile, analytics, cloud, and internet of things. Digital strategies were forcing companies around a rallying point but surprisingly there was not much distinction behind the rallying point more than, “I want to be the Amazon or Uber of my industry”. But Jeanne claims this is okay because competitive advantage is not going to be about strategy but instead about execution. And being the best at execution is going to eventually take you in a different direction than other market participants.

Competitive advantage today requires executing on integrated capabilities

At this point, Jeanne stressed that there is no competitive advantage in a single capability. This is why Uber has so much competition. But for established companies, advantage will come from an integrated established set of capabilities. “Competitive advantage will come from taking capabilities that others may or may not have and integrating them in ways that make something extraordinarily powerful”. This in Jeanne’s mind is how established companies can best startups because as we know, startups “can only do one thing well”. Integrating business capabilities provides a whole value proposition that is hard for others to copy.

Jeanne says that there is one more thing that existing companies need to get good at. They need to become responsive. Startups are constantly monitoring and learning what to do next. Think about Christopher Columbus and what an established company and a startup would do. The startup would pivot and learn how to do something different. Established companies need to learn how to do this too.

Now as we move into the digital economy, there are two strategies possible. And established companies must choose one to lead with. They are customer engagement or digitized solutions. Customer engagement means that every day, you wake up trying to figure out what you can do next to make customers love you. The great example that Jeanne gave is Nordstrom. She said that Nordstrom a few years ago was clearly being disrupted. And Nordstrom responded by creating a personalized shopping experience. This was enabled by combining capabilities around a transparent shopping experience and transparent supply chain. This of course is layered on top with predictive analytics. This allows them to predict what a customer needs and to know how to get it to them regardless of channel.

The second strategy is digitized solutions. Here you figure out what customers need that they don’t know they need. GE is doing this today as an industrial company. They are moving the value from the physical asset to asset performance management.

Her parting remarks

If your company has not embraced either of these then it doesn’t get the digital economy. You need to pick one to execute now. Enterprise Architects have a major role to play here. In the past, architecture was largely a divide-and-conquer approach. Today it is about integration. Today architecture is about empowering and partnering. We need to architect for agility. This means flatter organizations. Today, we need to be able to use data for decisions. The jobs of architects are incredibly important. You see the change that is necessary and you are in a unique position to help get your company there.

By Myles F. Suer, Chief Platform Evangelist, Informatica

Myles Suer acts as a Chief Platform Evangelist at Informatica Corporation. In this role, Mr. Suer is focused upon solutions for key audiences including CIOs and Chief Enterprise Architects and the application of Informatica’s Platform to verticals like manufacturing. Much of Mr. Suer’s experience is as a BI practitioner. At HP and Peregrine, Mr. Suer led the product management team applying analytics and big data technology to the company’s IT management.

Mr. Suer has also been a thought leader for numerous industry standards including ITIL and COBIT. As part of this, Mr. Suer was a reviewer for the ITIL Version 3 standard. For COBIT, Mr. Suer has written extensive. Most recently, he published in COBIT Focus, “Using COBIT 5 to Deliver Information and Data Governance”. Prior to HP, Mr. Suer led new product initiatives at start-ups and large companies. This included doing a restart of a Complex Event Processing Company. Mr. Suer has also been a software industry analyst. Mr. Suer holds a Master of Science degree from UC Irvine and a 2nd Masters in Business Administration in Strategic Planning from the University of Southern California.

Twitter: @MylesSuer

Further Reading

Jeanne Ross of MIT/CISR talks on Digital Disruption

Should the CDO drive corporate Digital Disruption?

The Importance of data in Digital Disruption Via @ComputerWorld

What is the role of government in Digital Disruption?

Are you acting like a software company? Your business may depend upon it

Using data and IT to gain Competitive Advantage

Leadership in an age of  digital disruption

Business model change: how does digital disruption drive the need for it?

@theopengroup

 

Leave a comment

Filed under digital strategy, digital technologies, Digital Transformation, Uncategorized

From Solution to Enterprise Architecture with the ArchiMate® Language:  An Interview with Ryan Kennedy

By Iver Band, Enterprise Architect at Cambia Health Solutions and Vice Chair, The Open Group ArchiMate Forum

I recently sat down with my Cambia Health Solutions colleague Ryan Kennedy.  Ryan is an architect with whom I have worked over the last year and a half on a variety of projects that benefit Cambia’s Healthcare consumer and group customers.  After noticing how Ryan has used the ArchiMate® language to expand his personal contribution to the company, I decided to get his perspective on the language, including the new ArchiMate 3.0 standard.


Iver
: What is your professional background?

Ryan
: Prior to becoming an architect, I was a software development engineer for over a decade, designing and implementing solutions across a broad range of organizations, from stable enterprise to volatile startup.

Iver
: How did you encounter the ArchiMate language?

Ryan
: Part of the onboarding process for new architects at my company is a bootcamp-style introduction to the ArchiMate language and its practical application.

Iver
: What were your first impressions?

Ryan
:  My first impression of ArchiMate was that it is very easy to learn if you know Unified Modeling Language (UML).  My second thought was, “Wow, now I can design all the things!”  It is a quantum leap from a grammar that can describe software, to a palate capable of representing the remainder of the enterprise.

Iver
: How have you used the language since then?

Ryan
: I use ArchiMate almost daily, and I treasure the power it gives me to quickly and effectively communicate my solutions to all manner of stakeholders, from business owners to software developers.

Iver
: For what would you recommend the language?

Ryan
: For any aspect of the enterprise that needs design, description or analysis for a broad range of stakeholders.  This includes motivation, strategy, business process, applications, technology, implementation, and migration.

Iver
: What are you doing with the language now?

Ryan:
My current duties mostly revolve around design and estimation of new feature work for sizing, budgeting, and ultimately making implementation choices.  For a new capability, I usually start with the business concerns.  For more technical solutions, I may start at the application or technology layer.  Either way, the traceability of cost and value across layers is what I’m usually trying to communicate at this phase, along with risk analysis.Iver: What are your impressions of the ArchiMate 3.0 language?

Ryan
: Capabilities!  Making capabilities first-class citizens should help us improve our portfolio planning and valuation.  Also, groupings really mean something now which is cool.  If your organization is anything like mine, tagging is important for your data.  Groupings are a great way to tag your ArchiMate concepts.  Also, you may have the same actual concept represented as different ArchiMate concepts in different viewpoints.  Groupings can keep these things together as an abstract, layer-agnostic concept.  Further, you can then describe relationships between aspects of disparate concepts, which should allow a lot more freedom and nuance in your design.Iver: What additional uses of the language do you see based on the 3.0 version?

Ryan
: With the addition of the strategy and physical capabilities, the language is capable of modeling almost any aspect of business or technology.

Iver
: What are your tips for getting started with the language?

Ryan
: Flashcards!  There are a lot of concepts to memorize!  Other than that, my UML background was enough to become fluent in ArchiMate in a few weeks, and I’m fortunate to have expert peer reviews for continuous improvement. If you have no visual modeling background, a formal course is probably in order.
By Iver Band, EA, Cambia SolutionsRyan Kennedy (left) giving his impressions of the ArchiMate language to Iver Band at Cambia Health Solutions in
Portland, Oregon

Iver Band
 is an Enterprise Architect at Cambia Health Solutions, where he uses the ArchiMate language continuously to develop strategic architectures, guide solution development, and train other architects. Iver is also Vice Chair of The Open Group ArchiMate Forum, co-author of the ArchiMate certification exams, and a frequent writer and speaker on Enterprise and Solution Architecture.  Iver is TOGAF and ArchiMate Certified, a CISSP, and a Certified Information Professional.

@theopengroup  @ArchiMate_r  #ArchiMate

1 Comment

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, Standards, standards, The Open Group

What’s New in ArchiMate® 3.0

By The Open Group

This summer The Open Group ArchiMate® Forum will make available the latest version of the ArchiMate Specification®, version 3.0, with a series of announcements and events to take place throughout the months of June and July. The official announcement was featured at the IRM Enterprise Architecture Europe Conference in London on June 14.  Additionally, a live webinar is scheduled for June 15 to promote the new standard. The webinar will include practical applications for the new standard, as well as its relevance for business modeling and business transformation support. A white paper will also be published and available here. In July, the Monday plenary and tracks at The Open Group Austin 2016 event will be dedicated to speakers, panels and use cases for the new standard.

The ArchiMate Specification is a modeling language that enables Enterprise Architects to describe, analyze and visualize relationships among architecture domains using easy to understand visuals representations. It provides a common language for describing how various parts of the enterprise are constructed and how they operate, including business processes, organizational structures, information flows, IT systems, and technical and physical infrastructures. In a time when many enterprises are undergoing rapid change, ArchiMate models help stakeholders design, assess and communicate those changes within and between architecture domains, as well as examine the potential consequences and impact of decisions throughout an organization.

The latest evolution of the standard continues to improve collaboration across multiple functions including strategists and business executives, enterprise and business architects, portfolio and project managers, information and applications architects, technology stakeholders and solutions architects. New features in the specification include:

  • Elements for modeling enterprises at a strategic level, including mapping capabilities, resources and outcomes
  • Modeling support for physical materials and equipment
  • Improved consistency and structure within the language
  • Improved usability and alignment with other standards, such as TOGAF®, BPMN, UML and BMM

This version of the specification will also include refinements such as:

  • Improvements and new elements to represent how architectures evolve over time through implementation and migration
  • Improved grouping capabilities for connecting different elements to see how they’re related
  • Cross-layer dependencies, alignments and relationships (to correlate business applications and technology, for example)
  • Mechanisms for customizing the language for specialized or domain-specific purposes and address specific real case situations.

The ArchiMate Specification is unique in that it provides a graphical language for representing enterprise architectures over time, including strategy, transformation and migration planning, as well as the motivation and rationale for the architecture. The standard has been designed to be as compact as possible, yet still usable for most enterprise architecture modeling needs.

ArchiMate 3.0 also furthers the relationship between the ArchiMate language and the TOGAF ADM.

By The Open Group

 

Certification programs for version 3.0 of the specification will follow this fall. In the meantime, current certification programs will remain active. Once available, a bridge certification will be also available for those choosing to transition from the current version of the specification to 3.0.

For more on ArchiMate, please visit: http://www.opengroup.org/subjectareas/enterprise/archimate.

@theopengroup @ArchiMate_r  #ArchiMate #ogAUS

1 Comment

Filed under ArchiMate, ArchiMate®, Certifications, EA, Enterprise Architecture, Enterprise Transformation, IT, Standards, TOGAF®

Enterprise Architects “Know Nothing”: A Conversation with Ron Tolido

By The Open Group

It has been well documented that the digital economy is sending many companies—not to mention industries— into a tailspin. Customer expectations, demands for innovation and a rapid change are creating an IT landscape that is not only difficult to manage but nearly impossible to predict. And according to Capgemini’s Ron Tolido, Enterprise Architects need to prepare to function in a world where they have no idea what type of solutions and innovations their clients may need, even in the near future—a world where Enterprise Architects “know nothing.”

Tolido, who spoke at The Open Group London 2016 in April, believes organizations must begin to look to “I don’t know” architectures if they are to survive in the digital economy. Traditional IT methods and architectural practices that were established during the 1980s and 1990s are no longer relevant in the digital age.

Because customer and business needs are constantly changing there really is no way to know what IT landscapes will look like in the future or what type of solutions organizations will need, Tolido says. Therefore, rather than asking clients what they need, IT must instead provide users an architected platform of services that can be mixed and matched to meet a variety needs, enabling business customers to go in any direction they want.

As such, Tolido says Enterprise Architects in this emerging digital era are comparable to the character Jon Snow from HBO’s Game of Thronesa character who is often told “You know nothing.” Like Jon Snow, today Enterprise Architects effectively know nothing because businesses have no idea what the future will hold, whether two days or ten years from now. With new business scenarios developing in real-time, architectures can no longer be painstakingly planned for or designed.

So where does that leave Enterprise Architects? What can they offer in a world where they know nothing and are heading blindly into an environment that is constantly in flux?

Tolido says it’s time for enterprise architectures to stop trying to make predictions as to what architectures should look like and instead provide the business a digital platform that will allow for a new style of architecting, one that drives continuous transformation rather than requirements-driven, step-by-step change.

To do this, Tolido says Enterprise Architects must enable “the art of the possible” within organizations, providing their clients with a catalog of possibilities—a listing of potential things they could be doing to help companies continually transform themselves.

This is a huge shift for most IT departments, Tolido says, which are still stuck in the mindset that the business is different from IT and that business requirements must drive IT initiatives, with architecture sitting somewhere between the two. No longer can architects be content to place architectures somewhere in the middle between the business and IT, Tolido says, because in the next generation of IT—the era of the platform—there is no distinction between business and IT. They are one and the same. With the “third platform”—or Open Platform 3.0™—the platform must allow the business to continually adapt to the needs of customers and market forces.

This brave new world will also require Enterprise Architects to become more adaptable themselves and give up control of their architectures, Tolido says. The role of architects is evolving with them becoming business enablers, or platform “maesters.”

Currently, many established enterprises are having a difficult time adjusting to this new reality; thus all the digital disruption we are seeing across industries, Tolido says. Start-ups and newer technology players have some advantage here because they are already in a state of change and their systems have been designed to deal with that.

One way, Tolido suggests, that enterprises can make transformation easier on themselves would be to create a “parallel IT universe” alongside their existing systems that explores a more service-oriented model and allows for them to transition. Although such a system might cannibalize existing services or products, it may also be the only way to keep up with disruptive market forces. “Better to eat yourself and be your own disruptor than have someone else do it to you,” Tolido says.

As “platform maesters,” Enterprise Architects will also need to become much more proactive in helping company stakeholders understand the necessity of a platform play for continuous business transformation. That means proving that the EA role is much more about designing a continuously enabling platform than actually designing solutions, which is a shift in role for EAs. Tolido believes EAs must also become better at telling the digital story and outlining the business possibilities that services can enable. “They need to become real change agents. This will require more imagination from architects as well.”

Enabling unhindered, continuous transformation may actually allow businesses to move closer to The Open Group vision of Boundaryless Information Flow™, Tolido says. Standards will have a significant role to play here because companies designing platforms that allow for constant change will need the help of standards. The work being done in The Open Group Open Platform 3.0 Forum can help organizations better understand what open platforms designed for micro services and ad hoc application composition will look like. For example, Tolido says, the concept of the Open Business Data Lake—an environment that combines services, data retrieval and storage in a fluid way to provides dynamic outlets and uses for the data, is an indicator of how the landscape will look differently. “Standards are crucial for helping people understand how that landscape should look and giving guidance as to how organizations can work with microservices and agility,” Tolido says.

Despite all the upheaval going on at companies and in IT today, Tolido believes these are exciting times for IT because the discipline is going through a revolution that will effect everything that businesses do. Although it may take some adjustments for Enterprise Architects, Tolido says the new landscape will provide a lot of compelling challenges for architects who accept that they know “nothing”, go with the flow and who can adapt to uncertainty.

“It’s a new world. There’s more change than you can absorb right now. Better enjoy the ride.”

@theopengroup

By The Open Group

Ron Tolido is Senior Vice President and Chief Technology Officer of Application Services Continental Europe, Capgemini. He is also a Director on The Open Group Governing Board and blogger for Capgemini’s multiple award-winning CTO blog, as well as the lead author of Capgemini’s TechnoVision and the global Application Landscape Reports. As a noted Digital Transformation ambassador, Tolido speaks and writes about IT strategy, innovation, applications and architecture. Based in the Netherlands, Mr. Tolido currently takes interest in apps rationalization, Cloud, enterprise mobility, the power of open, Slow Tech, process technologies, the Internet of Things, Design Thinking and – above all – radical simplification.

 

7 Comments

Filed under Boundaryless Information Flow™, Business Transformation, Data Lake, digital technologies, Enterprise Architecture, enterprise architecture, Enterprise Transformation, Internet of Things, IoT, Open Platform 3.0, Ron Tolido, Standards, The Open Group

Keys to Enterprise Architecture Success

By Stuart Macgregor, CEO, Real IRM Solutions and The Open Group South Africa

Avoiding the perils on the way to successful Enterprise Architecture

Enterprise architecture (EA) is more relevant today than ever before – considering the accelerating pace of technology adoption, many new and disruptive market forces, hyper-competitive environments, and rapidly changing business models.

Together, these present a burning requirement for many organisations to ‘digitise the enterprise’.

EA supports the organisation develop an holistic representation of the business, its information and technology. This provides a business tool for managing complexity and change.

The myriad benefits from successful EA practices include:

  • Competitive advantage – with so few organisations “getting it right”, having a business appropriate and sustainable EA function allows the organisation to respond to change with greater speed, and derive huge competitive advantage.
  • Market reputation – EA is essential for the organisation to promote a reputation of being well-governed (for example, EA allows the organisation to comply with King III and other governance/compliance requirements). EA acts as the crucial linchpin between corporate governance and IT governance.
  • Business transformation – EA supports major business transformations, by clearly understanding the current state, and clearly articulating the desired end-state. In this way, EA provides a clear roadmap for transformation
  • Portfolio rationalization – a structured approach to EA helps with reducing the size and complexity of the organisation’s technology estate, and removing any duplications within the application and technology portfolio.
  • Strategic support function – professional EA consulting services support the efforts of many critical areas within the enterprise – such as strategic planning, governance, risk and compliance, and solution architecture

In essence, EA facilitates the fusion between business and technology based on the fact that if the organisation cannot change its systems, it cannot change its business. New entrants are often more ‘digitally agile’: they have the ability – for example – to embrace new cloud platforms without being tied to millstone of legacy systems and processes.

The strategic theme that underpins the EA practice, and helps guard against failure, is that of ‘running the EA practice like a business, with a clearly-defined solution offering’.

Keeping this philosophy top-of-mind – across the entire ambit of people, tools, process, content, and products/services – is fundamental to ensuring that one’s EA practice is business-appropriate, sustainable, and ultimately successful. By running EA as if it is a business in its own right, in support of the enterprise’s strategic goals, the EA capability is positioned to evolve in scope and importance, and add increasing value to the enterprise over time.

However, so many EA programmes fail to achieve meaningful results. More often than not, they either end up on the scrapheap of failed IT programmes and wasted investments, or limp along with limited and isolated impact within the broader organisation.

So, why do EA programmes so often fail?

The role of the Chief Architect in ensuring EA success

Analysts confirm that the single biggest reason for failed EA programmes is lack of leadership skills within the core elements of the guiding coalition and the EA team. At the nucleus, the Chief Architect is required to lead by example and inspire others, while remaining acutely tuned into business’ needs.

Acting as the keystone in the EA structures that are being built, the Chief Architect must be flexible enough to continually adapt the business case for EA, but remain unwavering in the eventual vision – that of modernising and optimising the way the organisation functions.

The resilience of the EA function ultimately depends on the strengths of the Chief Architect.

As EA inevitably takes some time to generate sustainable returns, the Chief Architect must maintain the enthusiasm of executive stakeholders and business partners, while dealing with the ever-present threat that some individuals may revert back to old habits, divert funds to other projects, or focus on short-term wins.

This is a delicate balance, and the skills that qualify someone as a great architect don’t necessarily make them a strong leader. The most essential attributes include business acumen, the ability to translate technology into simple business outcomes, the ability to listen, communicate, present to groups, articulate the vision of the EA function, and inject enthusiasm for the EA practice.

Of course, it goes without saying that the Chief Architect must also possess the right technical skills which allow her to guide and govern the EA portfolio. In staffing the EA function, organisations should consider candidates in the context of defined career ladders and skills assessments. It is only with the right skills background that the Chief Architect will be in a position the strategic importance of the EA function within the first year of their tenure, or the practice is at risk of dissipating.

Leadership also includes aligning the differing EA visions held by the various business units and stakeholders. Everyone has a slightly different spin on what EA should achieve, and how the organisation will achieve it. While keeping stakeholders involved in the project, the Chief Architect must influence, guide, and delicately meld these visions into a single cohesive EA strategy.

Finally, the EA practice is at risk if the Chief Architect and her team are not skilled in communicating with key stakeholders across both business and technology domains and at multiple levels within the organisation. Results need to be clearly measured and demonstrated to the business. The EA vision must be constantly reinforced throughout the programme as the practice develops in maturity.

Setting up the EA team for success; the core EA team

As important as her role may be, the Chief Architect cannot ‘go it alone’. Ensuring that the right core Enterprise Architecture (EA) team is in place is the next important step in avoiding potential EA failure. Led by a strong guiding coalition and steering committee, the team needs to consider how to manage the work, how to control delivery against the plan, how any blind spots will be identified, and how they will engage with the rest of the organisation.

None of this can happen just by accident. The starting point is to conduct a critical analysis of the skills requirements, and match this with the right people in the right roles. Any silos, or ‘stovepipes’ should be dismantled, in favour of greater collaboration and knowledge-sharing – giving the Chief Architect better visibility of everything happening within the team.

So, with a strong EA team at the nucleus, and skilled individuals in the various areas of the organisation, the Chief Architect is able to allocate resources efficiently and generate the best returns in the least possible time. Excellence in the execution of the EA tasks, from beginning to end, is only ever possible with quality staff involved.

There is an ever-present risk that the core team gets pulled into detailed operational work like solution delivery – while the strategic architectural role gets deprioritised. Another common risk is that the EA practice becomes something of a ‘dumping ground’ for disparate IT team members. For this reason, when a new Chief Architect is appointed, one of her first tasks is to assess the team capabilities, restructure, replace and recruit where necessary.

The goal is to ensure the right portfolio of skills is spread across the entire EA discipline – people with the right qualifications, tool proficiencies and psychometric profiles are working together in the optimal structure.

Organisational positioning

To have legitimacy among executive stakeholders, and to avoid knee-jerk, short-term approaches that merely address symptoms (rather than dealing with root causes), the appropriate placement of the EA function is fundamental to its success.

For example, if EA is housed within the area of the Chief Technology Officer then we can expect the focus to be all about technical architectures and solutions support. If it’s positioned under the Chief Information Officer, the focus is often more on supporting solution architectures.

Reporting into business strategy and governance structures reduces technology-centric thinking. Whichever is the case, we find that organisational structure shapes the behaviour and the strategies of the teams.

Appropriate structure and alignment within the organisation is critical for ‘expectation management’. We’ve seen many cases of senior stakeholders (within whose portfolio the EA function resides) making promises to executives, shareholders, or markets – creating unrealistic expectations of what EA is capable of doing at a particular level of maturity.

The organisational design must be fit-for-purpose, depending on the firm’s specific requirements and the state of maturity. The EA function will be hindered if its scope is not clearly defined, and does not span all of the horizontal EA domains (business architecture, information architecture, data architecture, application architecture and technology architecture) and vertical domains (integration, security and solution architecture).

If these areas are fragmented, it becomes tougher to answer questions around how they will integrate, who will be responsible for what, and how the organisation will build an integrated view of the target architecture. In highly federated, decentralised or geographically-dispersed organisations, the positioning becomes even more complex –  often being required to morph according to changing business priorities. This requires a clear understanding of what EA capabilities are performed globally, regionally and locally.

The EA team needs to simultaneously build the EA capability (and start delivering results), while selling this positive story to executives – in order to achieve their further buy-in. This may place greater pressure on the teams in the short-term, as milestones and commitments are thrust into the spotlight and must be met. We recall the principle of ‘publish or perish’, which is crucial to maintaining the involvement and support of executive stakeholders.

Executive sponsorship

The business executive must empower the EA function with a defined and widely communicated mandate. Failure to do so often results in ‘turf wars’ between the EA practice and related areas of the organisation, such as the Programme Management Office or Service Management.

To build on early momentum, EA education and communication should filter down from above as one of the organisation’s highest priorities. This helps to foster business stakeholder engagement and ensure that EA content is used in the right ways “on the ground”.

Executives are also able to remove many of the obstacles that could otherwise bring on the demise of EA in the organisation. Executive sponsors may be called on to influence budgets and vendor selection, or make the necessary structural changes to the teams, or ensure that architecture governance remains firmly on the agenda.

So, in summary, it is critical to have the right people, under the right leadership (the Chief Architect and her guiding coalition), working in the right structure within the organisation. Without all three of these things in place, the EA practice is at great risk of failure.

Ivory Tower syndrome

A common reason for the collapse of EA initiatives, is architects who become overly-enamoured with the conceptual aspects of their work. They return from their retreats away from the business, with elaborate frameworks, and little practical guidance on how to implement them.

These concepts will be presented to key influencers within the organisation, most of whom will not understand the content, so their complex reference architectures will be ignored. In this way, the EA team is perceived as living in an Ivory Tower – disconnected from the business and alienating stakeholders – often leading to the withdrawal of support and sponsorship from key people.

These complex frameworks are built in isolation from the business stakeholders on the ground.

Investing too much time in detailed documentation of the “as-is states”, and creating vast arrays of diagrams, gives the impression that progress is being made, when in reality, this flurry of visible ‘activity’ is being mistaken for progress.

This academic approach to EA leads to inertia in decision-making, a state of ‘deferred commitment’ where the fear of failure leads to an inability to act. The EA practice lives by the principle of “publish or perish” (describing how critical it is to deliver tangible outputs).

This leads to distorted perspectives, where the architect’s views of the business architecture and other architecture domains are not necessarily shared by their key stakeholders.

Architects who dogmatically force their models on stakeholders – without fully appreciating the changing business’ requirements or tailoring their services to meet the business’ demands – are bound to fail.

By focusing on tangible outputs, and running the EA practice like a business, architects can effectively maintain a stakeholder-centric approach to delivering business value.

Architects need to ‘get their hands dirty’ – such as getting involved in the actual modelling, investing time in mentoring people in architecture skills, closely following the business’ needs, and evolving the EA artefacts.

This should be combined with strong marketing and communications efforts – where architects constantly communicate and evangelise the value of the EA practice to business stakeholders.

If not, the team risks the ‘Ivory Tower syndrome’ setting in, and will lose the backing of the C-suite. Even if budgets are still provided for, the bigger work surrounding EA – like maturing the EA capability, business transformation and change management – will not be possible without active executive support.

@theopengroup

By Stuart Macgregor, CEO, Real IRM

Stuart Macgregor is the CEO, Real IRM Solutions and  The Open Group South Africa. Through his personal achievements, he has gained the reputation of an Enterprise Architecture and IT Governance specialist, both in South Africa and internationally.

Macgregor participated in the development of the Microsoft Enterprise Computing Roadmap in Seattle. He was then invited by John Zachman to Scottsdale, Arizona to present a paper on using the Zachman framework to implement ERP systems. In addition, Macgregor was selected as a member of both the SAP AG Global Customer Council for Knowledge Management, and of the panel that developed COBIT 3rd Edition Management Guidelines. He has also assisted a global Life Sciences manufacturer to define their IT Governance framework, a major financial institution to define their global, regional and local IT organizational designs and strategy. He was also selected as a core member of the team that developed the South African Breweries (SABMiller) plc global IT strategy.

Stuart, as the lead researcher, assisted the IT Governance Institute map CobiT 4.0 to TOGAF®. This mapping document was published by ISACA and The Open Group. He participated in the COBIT 5 development workshop held in London in 2010.

 

1 Comment

Filed under Business Transformation, EA, Enterprise Architecture, Enterprise Transformation, Standards, The Open Group

TOGAF® User Group Meeting – The Open Group London 2016

By The Open Group

On April 27, the second TOGAF® User Group Meeting was held at The Open Group London 2016. The session brought together TOGAF users and stakeholders to share information, best practices and learning, for the development of individual practitioners’ knowledge and the standard as a whole. Discussions revolved around how to better use TOGAF in practice within different organizations and industries, success stories and areas of improvement, as well as suggestions as to how the standard can be improved upon in the future.

Central Hall Westminster conservatory was packed, as Steve Nunn, President and CEO of The Open Group, opened the meeting with a warm welcome to the community. He heralded the session as an initiative that was ‘trailblazing’ the way for the development of TOGAF®, an Open Group standard, which now has more than 55,000 certifications.

The session was hosted by Terry Blevins, a Fellow of The Open Group and Director of The Open Group Governing Board. Terry has been involved in development of the TOGAF standard for years and has been a major contributor to its development. He stressed that as the community continues to grow, it’s so important to hear real-world experiences of those using the standard to get a broader perspective on what works, what doesn’t, and how it can evolve.

To achieve this, the TOGAF User Group staged an ‘Open Debate’. Fashioned on an Oxford-style debate, it was designed to tap into people’s feelings about the TOGAF standard and allow questions and different points of view to be shared around the room. Standard debating rules were explained, before the proposition declaration was laid out:

“The TOGAF® Architecture Development Method (ADM) is not agile and therefore there is a need to change the specification to make it agile.”

Arguing ‘For’ the proposition was Chris Armstrong, President of Armstrong Process Group, Inc. and internationally recognized thought leader and expert in iterative software development, Enterprise Architecture, object-orientated analysis and design, the Unified Modelling Language, use case driver requirements and process implementation.

Arguing ‘Against’ the proposition was Paul Homan, Technology Strategy Consultant for IBM for eight years. He is a Certified Distinguished IT Architect, specializing in Enterprise Architecture joining IBM from end-user environments, having worked as Chief Architect in both the UK Post Office and Royal Mail. Not only has he established Enterprise Architecture practices, but also lived with the results.

By The Open Group

Open Debate with Paul Homan and Chris Armstrong

In order to understand the audience’s view at the outset of the debate, attendees were asked to vote on their existing standpoint. A few hands showed support for changing the specification to make it agile, and a few abstained. However, most hands were raised against the proposition, agreeing that the ADM was already agile in nature.

Chris then had seven minutes to argue his case – that the TOGAF ADM is not agile and needs to change. He conceded that very few people would steadfastly ignore change within their organization and aim to respond to it badly, however in the whole 692 pages of TOGAF version 9.1, agile is only mentioned twice, agility 6 times and lean is not mentioned at all. Furthermore, the mere fact that there are 692 pages could be taken to indicate the lack of agility altogether. The crop circle diagram that underpins the whole framework appears linear and waterfall in appearance, and so lacking in agility by nature. He argued that the only way that the TOGAF ADM can realistically support an agile enterprise is by becoming agile itself.

Likewise, Paul put his seven-minute case forward – arguing that the TOGAF ADM is agile and does not require any changes to make it so. He made the point that as an architect, everything has to have a reference system, and that the TOGAF ADM is a framework for developing architecture, not a style guide. The specification is actually part of a wider ecosystem of material, including pocket guides, whitepapers, translations and qualifications, and all of these items help to move the enterprise away from project management bureaucracy, towards agile project development. Enterprise Architects, he said, should live by the oath: ‘I will apply for the benefit of the enterprise, all architecture practices that are required’. This is so as to make agile more meaningful and relevant. Instead of relying on the framework, agility is created through just enough architecture, coupled with the interpretation and implementation of the framework by the practitioner. Therefore, skills are the most important element in these projects.

Following these opening statements, TOGAF users were encouraged to ask questions to the pair. A couple of these, included below, give a flavor of the discussion:

Q: Chris, you counted the number of times TOGAF uses the word agile – but how many occurrences are there where it says you cannot be agile and processes must take a long time?

A: Chris –Just because TOGAF does not say you cannot be agile, does not mean it is agile itself. The best laid plans will not work if the people delivering it do not see where they fit in and translate their work to the project they are implementing. We are not recognizing significant changes in delivery from the waterfall practices of many years ago.

Paul – It’s a prioritization exercise – we need to worry about the behaviors of practitioners and the interaction of enterprise architecture functions within a project, rather than the spec and other incentives. Accessibility is key – we can help people access this body of knowledge without having to rethink the whole body of knowledge

Q: The TOGAF standard is a reference model and we need to adapt to the particular needs of each organization, so how do you handle that?

A: Paul – It’s all about consumption. We have to consider that somebody has to be able to consume the guidance that we want to provide as EAs within a development project. We want them to be aware of what matters to us from an EA perspective – we shouldn’t be trying to out-design them, we should just think about what is relevant to us that they are potentially not aware of. This comes back to understanding your consumer.

It’s a bit like someone that comes to service the heating in a house. The consumer is the house owner and the servicer has a tool bag, which in this case is the TOGAF standard. It has all the tools in it you might need. Boilers will change, but what is really changing in an agile world is that customer experience is evolving. This would include their presentation, reliability and professionalism – customers get a good experience from behaviors and style, not the toolset. The tool bag will remain the same, but behavior and how it is applied needs to change and get better.

Q: Chris, are you saying that we should be working in a completely agile fashion and that waterfall methods are no longer relevant?

Chris – We need to acknowledge the complexity of various different organizations, and we need to find the balance between always evolving technology and approval times, for example. Agility in enterprise architecture is often compensating for a lack of agility throughout the rest of the enterprise – maybe solution delivery teams wouldn’t have to be so agile if everywhere else in the company was a bit more agile.

Q: The crop circle is a waterfall model, this is reflected in the spec itself, but if you keep the framework are we missing the opportunity to address different levels of agility?

Chris –  We need to change the crop circle. This might be met with great resistance but it implies that you have to wait to complete one phase to start the next one – you should be doing certain processes every day and not waiting to go from one stage to another.

Paul – The reader is lulled into the idea that there is a sequence and you must complete one phase before another. I think that there is always going to be a weakness in condensing a large body of knowledge into one diagram, and there is always going to be approximation which is what has happened from TOGAF® 9.1 into the crop circle. There are things we can assume – but this is why the spec says it’s not intended to be waterfall.

The two speakers then summarized their arguments. Paul reinforced his argument that the ADM is fit for purpose as a Hippocratic Oath for EAs, but what matters is the changes in our behavior to complement this. Chris stated that the spec does need to change, to add supplemental guidance so people can be guided in how to implement TOGAF as an agile framework.

When it came to the final vote from the audience, more people had been persuaded by the ‘for’ argument, to change the ADM spec, however the ‘against’ argument still had more support in the room. This conclusion demonstrated that there was a display of two sound and compelling arguments for each side, and Terry noted that more time for questions would be needed at the next debate!

Following the debate came two breakout sessions; ‘The Roles of People in TOGAF Driven Architecture Initiatives’ from Len Fehskens, Editor, Journal of Enterprise Architecture (AEA), and ‘Using TOGAF® for Digital Business Transformation’ from Sonia Gonzalez, The Open Group Architecture Forum Director. These sessions were used to open up a freer dialogue between users, to discuss their ideas and experiences around  the TOGAF standard.

Check out video highlights of the debate here!

Please join us at the next TOGAF® User Group Meeting taking place at The Open Group Austin 2016 July 18 – 21!

@theopengroup #ogLON #ogAUS

 

 

Leave a comment

Filed under Association of Enterprise Architects, Certifications, EA, Enterprise Architecture, Professional Development, standards, Steve Nunn, The Open Group London 2016, TOGAF®, TOGAF®, Uncategorized