Management Levels & Enterprise Architecture

https://www.linkedin.com/pulse/management-enterprise-architecture-matthew?trk=v-feed

Creating a Business Case for Enterprise Architecture Projects

https://www.corso3.com/blog/ea/creating-a-new-business-case?utm_content=34351935&utm_medium=social&utm_source=linkedin

The Great Escape: “EA is not about IT!”

https://enterprisechess.com/2015/04/27/the-great-escape-ea-is-not-about-it/

4 Myths About Enterprise Architecture

http://community.mega.com/t5/Blog/4-Myths-About-Enterprise-Architecture/ba-p/12515?device-view=desktop

Enterprise Architecture Approach in an HE Institution: 10 Practical Steps

http://enterprisearchitect.blogs.ilrt.org/category/ea-in-higher-education/

10 More Practices for Enterprise Architecture

https://www.linkedin.com/pulse/enterprise-architecture-20-practices-matthew?trk=mp-reader-card

https://www.linkedin.com/pulse/enterprise-architecture-20-practices-matthew?trk=mp-reader-card

20 Enterprise Architecture Practices

https://www.linkedin.com/pulse/enterprise-architecture-20-practices-matthew

"Architecture is the thing between strategy and execution." -John Zachman

Avolution Blog

HOW TO BUILD AN EA ROADMAP: 4 STYLES TO CONSIDER

http://www.avolutionsoftware.com/about-us/news/how-to-build-an-ea-roadmap-4-styles-to-consider/

5 STEPS TO ACHIEVING A GREAT CUSTOMER EXPERIENCE THROUGH DIGITAL TRANSFORMATION

http://www.avolutionsoftware.com/about-us/news/5-steps-to-achieving-a-great-customer-experience-through-digital-transformation/

Enterprise Architecture: The CIO’s Snow Blower of Business Innovation

http://community.mega.com/t5/Blog/Enterprise-Architecture-The-CIO-s-Snow-Blower-of-Business/ba-p/10609

Getting the right Architectures Roles

https://www.goodelearning.com/Downloads/ViewOnline?resourceFriendlyUrl=getting-the-right-architecture-roles&resourcePdf=Case%20Study%20-%20Getting%20the%20right%20Architecture%20Roles.pdf

IT Planning Issues

http://briankseitz.wordpress.com/2014/10/14/it-planning-issues/

Enterprise architecture: The key to cybersecurity

 

http://www.zdnet.com/enterprise-architecture-the-key-to-cybersecurity-7000021410/?utm_source=Intellyx+Cortex+Newsletter&utm_campaign=9a20c6e45c-Setting_the_Bar_Draft_6_1_2014&utm_medium=email

Beware the Dangers of Bimodal IT

 

http://intellyx.com/2014/10/12/beware-the-dangers-of-bimodal-it/?utm_source=Intellyx+Cortex+Newsletter&utm_campaign=9a20c6e45c-Setting_the_Bar_Draft_6_1_2014&utm_medium=email&utm_term=0_1e589453ce-9a20c6e45c-222315785

5 Key Components of a Successful Enterprise Architecture Function

http://blogs.salesforce.com/company/2014/08/enterprise-architecture-function.html

Creating and managing a successful enterprise architecture function requires a variety of different hard and soft skills. In addition, each company is different, and the enterprise architecture function needs to calibrate and align itself to the specific company.

With this in mind, there are five common features of a successful enterprise architecture function that apply to all companies:

1. Governance

Enterprise architecture (EA) requires governance, however not in the form of complex documents, forms or processes. The best governance starts with a simple, recurring dialogue across multiple functions facilitated by EA. I am always amazed at how valuable it is just to get cross-functional teams to talk.

Pick a specific topic, typically a critical pain point, which might be some business capability, and create a dialogue about how it works today. Each function will be able to share their perspective of how it “works,” and usually it’s educational for everyone in terms of learning how other groups are impacted. An enterprise effort can exist only when a cross-functional group of business functions prioritize that effort.

2. Talent

In my opinion, the best enterprise architects (EA) must have two critical qualities, pragmatism and business acumen, in addition to deep technical skills. Yes, it is important that they have good communication skills, good influencing skills, and are good at simplifying complex topics. But pragmatism and business acumen are critical as an Enterprise Architect.

A pragmatic EA is able to articulate current state, propose a future state and then pragmatically articulate a reasonable way to head towards that future state. Probably the hardest job of the EA is to find a path forward that is realistic given the current state architecture and the myriad of other constraints related to budget, resources and time. Perfection is the death sentence of enterprise architecture because it will lead to paralysis. Doing nothing means that systems will continue to atrophy. EA must find a way to move forward leveraging a pragmatic approach.

3. Executive Sponsors

For enterprise architecture to get real traction, you need the most senior level executive sponsors. The optimal situation is to get sales and customer service executives because revenue and customer are usually the highest priority in most companies. Regardless, get executive sponsors who have a strong, respected voice in your company. You don’t need every executive as a sponsor but you do need a critical mass. The reason for executive sponsors is that some of the tough decisions need to be driven top-down—only so much can be lead through grassroots activities. Common enterprise standards, policies, and governance require executive sponsorship.

4. Scope

Be careful not to over-scope EA. Pick a few key enterprise-level business pain points and start with those. Most EA teams have limited resources and budget (like all of IT) so pick your priorities wisely. Do a few things really well and avoid the trap of trying to kick off too many initiatives and spread your EA team too thin. It is sometimes difficult to reduce your scope when there are many challenges to choose from, but partner with your business partners to determine one or two key focus areas.

5. Business Value

EA must demonstrate business value. This means that the business functions must feel and articulate that EA is a value-add. The best way to accomplish this is to focus on improving business capabilities so that the business teams really feel the positive impact of EA. For example, if entitlement or your sales compensation process are broken and the business sees those are critical capabilities, focus on those.
Be wary of just doing “systems consolidation” projects or “technical upgrade” projects. Yes these are necessary but may not provide tangible business value. Always include some “wow” projects such as mobile apps or collaboration solutions. Find visible and exciting projects that motivate your EA team and add business value.

Visit salesforce.com for more on how our products support the enterprise archtecture role and download the free guide to building enterprise mobile experiences, 10 Essential Elements of Great Enterprise Mobile Apps.

Enterprise Architecture: A Practitioner View

http://blog.opengroup.org/2014/09/17/enterprise-architecture-a-practitioner-view/

The identity of enterprise architecture

http://weblog.tetradian.com/2014/08/27/the-identity-of-enterprise-architecture/

The Missing Role of the Segment Architect

 

http://blog.goodelearning.com/togaf/missing-role-segment-architect/?_$ja=tsid:46982&utm_source=Good+e-Learning+Newsletter&utm_campaign=eea95251d3-Mailshot+-+26082014&utm_medium=email&utm_term=0_de6cfc91ca-eea95251d3-76513765

 

A segment is just a sub-division or subset of the full enterprise

Have you ever come across anyone with the title – “Segment Architect”? No? Well neither have I. And yet the role is one that crops up in several parts of the TOGAF® documentation. So what is this missing role of the segment architect?

I’ll start by listing the places in TOGAF where you will find mention of this elusive role:

• In the Architecture Skills Framework (Chapter 52) TOGAF describes three categories of architect – Enterprise Architect, Solution Architect, and Segment Architect.
• In Applying the ADM across the Architecture Landscape (Chapter 20) and the Architecture Repository (Chapter 41), TOGAF divides the architecture landscape into three levels of granularity or types of organizing framework:
  • Strategic Architectures, which show a long-term summary view of the entire enterprise, supporting operational and change activity and allowing direction setting at an executive level.
  • Segment Architecture, which provides more detailed operating models for areas within an enterprise, supporting operations and change, through direction setting and architecture roadmaps at a program or portfolio level.
  • Capability Architectures, which show in more detail how the enterprise can support a particular capability by developing architecture roadmaps to realize capability increments.
    [Note: the idea of partitioning the architecture according to these three levels is discussed further in Architecture Partitioning (Chapter 40)]
• This idea of partitioning the architecture into three levels of granularity is also discussed in the Introduction to the ADM (Chapter 5). In this chapter TOGAF talks about how architecture artifacts need to be integrated across these levels.

The key point here is that segment architecture is simply “a detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity” (link).

In other words, a segment is just a sub-division or subset of the full enterprise. Any sub-division or subset, however you choose to make that subdivision.

Some organizations have segments that correspond to the organization structure. For example, within a large international bank there might be a Retail Bank Segment and a Corporate Bank Segment. But the architect responsible for these areas would probably be called “Retail Bank Architect”, or possibly be given a more generic title like “Business Unit Architect”.

Other organizations have architects responsible for particular sub-domains. For example, there might be an architect responsible for Payments, Customer Relationship Management, or Fraud. The job title for these architects might include the domain name, such as Product Architect, or it might reflect a functional area within a business, such as Sales and Support Architect. TOGAF describes four high-level domains – business, data, application and technology – and these are often used in the job titles for architects focusing on those subjects.

TOGAF is not actually describing a particular role, but more of a type of architecture role. If we go back to the summary of the three types of Enterprise, Segment and Solution architect in Chapter 52, it becomes easier to see what TOGAF means by segment architecture.

All types of architectural role have responsibility for the planning, defining, documenting and managing some aspect of the architecture – it’s just at different levels of detail, scope and domain subject matter.

• The Enterprise Architect looks after the architecture at a landscape and technical reference model level. In other words – it’s a broad view across the whole of the enterprise. It’s a role that provides holistic overview and coordinates all views and viewpoints. Often the Enterprise Architect might also lead a team that consists of Segment and Solution Architects. Typically the enterprise architect relies on the segment and solution architects to provide detail, so that the enterprise architect can focus on how everything works together in a systemic, collaborative, synergistic way.
• The Segment Architect focuses on a specific aspect of the business or organization. They look up to the enterprise architect to provide the overall context of the work they do. But they also need to look sideways to other segment architects – to make sure that their segment fits with the architectures in those areas.
• The Solution Architect operates at a system or subsystem level – which often means that they are directly engaged in projects and architecture delivery. The solution architect is the one that knows the detailed information about systems, products, and technologies; for example, they might be the expert on data warehouse architectures. A solution architect looks to the segment and enterprise architecture roles to provide the contexts in which a detailed architecture fits.

The role of Segment Architect isn’t missing; it is more veiled or obscured. It is not obvious because architects are not typically given the title of Segment Architect. But when we search further we find that the distinction between “enterprise”, “segment” and “solution” helps to explain the key difference between the three types of architecture role.

Look within your enterprise and you will find plenty of examples that fit the Segment Architect type of architecture role.

TitanVine Blog

http://www.titanvine.com/category/enterprise-architecture/

My EA presentations, articles, site, books and posts for the last eight years or so

http://www.ebizq.net/blogs/ea_matters/2014/08/my-enterprise-architecture-site-books-presentations-and-posts-for-the-last-eight-years-or-so.php

What employers want from enterprise architects

http://www.zdnet.com/what-employers-want-from-enterprise-architects-7000024300/