Enterprise Technical Architect Job Posting for Salt Lake City or Houston

July 26, 2013

If interested, contact Kevin Welch at Kevin.Welch@zionsbancorp.com or 801-844-4720.

Zions Bancorporation is now accepting applications for our Enterprise Technical Architect position located in West Valley City, UT, or Houston, TX. The ideal candidate for this position will have the skills and experience to architect and deliver mission-critical enterprise grade applications and systems.

About Us

Zions Bancorporation is a West Coast regional Banking/Financial organization with operations in Arizona, California, Colorado, Idaho, Nevada, New Mexico, Oregon, Texas, Utah and Washington. We have 10,000 employees with 40 Billion in managed assets. Zions Bank is proud to be an S&P 500 company. To better familiarize your self with our company visit us at: http://www.zionsbancorporation.com/

Responsibilities:

-Provide broad IT architecture support for variety of business and technology projects.

-Analyze enterprise business context to derive technical architecture.

-Define technology standards, principles and governance that guide technology decisions for the enterprise.

-Design and lead the implementation of an enterprise architecture based on business requirements and IT strategies.

-Support executive management and project teams in technology decisions and implementation of technology strategy

-Oversee and facilitate the evaluation and selection of hardware and software technology and product standards

-Facilitate consistent business analysis, information acquisition analysis and design, data access analysis and design, archiving and recovery strategies, security, and change management at the enterprise level

-Develop a road map of the evolution of the enterprise application portfolio from current to future state

-Participate in enterprise strategy development, including environmental analysis, opportunity identification, value cases and business innovation portfolio development

-Participate in enterprise architecture development, including business architecture, information architecture, application portfolio and technical architecture

Requirements:

-Experience with planning, architecting and delivering mission-critical enterprise grade applications and systems

-Experience in guiding buy/build decisions, distributed systems, system design and development

-Experience with project management, organizational, time management, customer relationship, communications, and presentations skills

-Ability to estimate the financial impact of technical architecture alternatives

-Ability to understand the long-term and short-term perspectives of situations

-Ability to apply multiple technical solutions to business problems

-Ability to quickly comprehend the functions and capabilities of new technologies

-Thorough understanding of IT management processes

-Experience in multiple technology areas in large heterogeneous enterprise environments

-Experience in designing and implementing multi-tiered enterprise applications (J2EE, .NET, RDBMS etc.), EAI, and integration middleware

-Strong background and demonstrated knowledge of SOA and and object-oriented analysis and design

-Experience in the design and construction of information architectures that enable well-integrated transactional, collaborative and analytical systems

-Experience in application and infrastructure analysis and design

-Demonstrated knowledge of enterprise IT processes and service management concepts (e.g. ITIL)

·         Experience with business intelligence and data warehousing development techniques

·         Experience with relational database management systems and other data structures

-Demonstrated excellence in verbal and written communication at all organizational levels

-Ability to work independently and efficiently, managing timelines and expectations, and producing high-quality deliverables (documentation, presentations, research, etc.)

-Ability to analyze problems, process complex data, establish facts, and draw valid conclusions

-Experience in management or other leadership position a significant plus

-Banking or other Financial Services experience a plus

-Information Security experiences a plus

-Experience with new computing architectures and the implementation of networked computing structures emphasizing distributed computing; experience with e-commerce, Web architecture, and Internet/intranet development and implementation a plus

General Information

Requires a Bachelor’s in Computer Science, Engineering, MIS or related field and 8+ years of experience in information systems architecture, application architecture, software development, project management or engineering.

Equal Opportunity Employer


Lack of Enterprise View a Hindrance? Good Solution Architecture is Not Enough

November 7, 2011

We are consistently being exposed to ENTERPRISE architecture teams without an enterprise perspective in the deliverables and activities in which they are engaged.  Sometimes this is due to a cyclical shift in the priorities between defining enterprise architecture and applying enterprise architecture via solution architecture.  This is a normal, healthy shift that we see happening in maturing EA programs.  However, the occurrence I would like to touch on is when there has NEVER been an enterprise perspective, yet there is an enormous priority placed on solution architecture resources and activities.

I have to ask myself if these enterprise architecture teams understand what they are missing.  The enterprise perspective is embodied in activities and deliverables that are not only enterprise-wide in scope and objectives, but also forward-looking, strategic, holistic and business-driven.  Relative to solution architecture (SA), the goal of EA is to provide this enterprise perspective so that SA’s can guide the tactical, technical, siloed project-oriented activities to fit with the long term business and technical direction of the enterprise.  Without the enterprise perspective, the SA’s are only guiding projects to fit within the technical best practices and emerging trends from the perspective of an individual SA or SA group.  Valuable, yes, but not EA.

But there is an even greater impact to an organization of an EA without an enterprise perspective, and that impact is felt by other  planning groups relying on EA to provide that long-term, holistic, business-driven, strategic view.  Budgeting, portfolio management, change management, strategic planning, sourcing, and operations planning all tend to happen with an eye on the short-term and tactical.  Without EA fulfilling its obligation, these plans are likely to be inconsistent, abandoned quickly, lead to waste, and ultimately, diminish confidence in the IT organization, the CIO and the IT management team.

The excuse that many EA groups are using is that there is a focus on the short term because of the economy, resource shortage or lack of business strategy from the enterprise leadership.   This excuse might hold weight for organizations just getting started with EA in the last 2-3 years, but what about the EA teams that have been operating for 5 years or more and NEVER developed the EA perspective.  Simply put, it is usually a lack of leadership and understanding of what is needed to create the enterprise perspective.  We counsel organizations to do the work to create a baseline of the enterprise perspective and use that to help leadership understand what the enterprise perspective is and how they can use it.  Good leaders will make use of it, and understand that now is the time to be looking forward.


EA Tips: Anchor Models

November 7, 2011

Anchor models are context diagrams that capture the essence of the enterprise as a simple graphic. They should be equally meaningful to both business and IT personnel and should be so intuitive that they don’t require a multi-page text narrative to understand. While we see many models created by EA teams, most are lower level “IT” models of business systems or technology components. Even models that attempt to represent the entire enterprise tend to be IT-oriented. While these models can be very useful, they don’t serve the same purpose as an anchor model.

The term “anchor model” represents a concept, not a specific format.  In our experience there is no such thing as the perfect template for an anchor model. The model must resonate with the broadest audience in as natural a way as possible. Therefore, the model should be in the language of the business it is depicting and is “good” only if it is meaningful to that organization. We have seen wildly different representations from different companies, yet each turned out to be exactly the right model. It’s one of those “you know it when you see it” phenomenon. When it is right, the model just makes sense.

Anchor models are basically top-level context diagrams describing the “enterprise”. They go by various names: company on a page, enterprise value network (EVN), concept of operations, operating models, root models, etc. These diagrams serve multiple purposes:

  • As a consistent view of the company – a context for common understanding, language/terminology, etc. It allows everyone to get on the same page in the simplest, most direct way possible, representing a “big picture, enterprise view”.
  • As a root for other derivative models (business, information architectures, business capability portfolios, etc.)
  • As a credibility building tool for the IT executives in interactions with their business counterparts
  • As a base model to super-impose various information systems, exposing overlaps, duplication, etc.

Creating a “good enough” initial anchor model is more art than science. It is a people-driven, collaborative exercise. A “starting point” model created by a sponsor usually helps kick off a productive session. We consistently observe several behaviors associated with the process, both good and bad, and have several tips to help you. Here are just a few:

  • Anchor models can be controversial and are challenging to create. Don’t let that stop you from trying.
  • Find passionate, business-knowledgeable people to start. Ideally, an anchor model should be something created by the business, not IT. An EA group is often the instigator to its creation and should act as catalysts to the process and not owners of the model.
  • Not everyone is going to be happy. Someone will always object to something in the diagram, and the tendency is to just “make it a little better”. Our advice, work in a small group and time-box the activity. We suggest a few hours initially.
  • Keep it simple, simple, simple, including only the significant parts of the organization. Resist the tendency to try to include everything a business does.
  • Look at value networks, internal and external to the organization. Expose internal functional blocks, flows of information and services in/out/between them. Include the full range of external stakeholders and the interactions with them in the diagram (customers, suppliers, partners, regulators/government, etc.)
  • Catalog your desired “functional hierarchy” to understand the main business functions performed. Avoid organizational constructs (departments, divisions, etc.). They are fluid and will undoubtedly change. Make your models as timeless as possible.
  • Relationships are at the heart of anchor models. Understand the flows of information (not data models) and how functional elements relate.
  • Timing is everything. We have seen good anchor models get no traction when presented to the wrong people at the wrong time.

There are many more tips that we can suggest. If you have a successful anchor model that resonates with your business, let us know. We’d like to hear your experiences and will share any other general pointers back to the community.

A strong anchor model, once complete, appears so obvious that many wonder why it was created. But that misses much of the point. It is the process of creating it that often yields the highest value.


George Paras and Tim Westbrock featured guests on A&G Webinar Nov. 16

November 7, 2011

Join George and Tim for a webinar on November 16, hosted by A&G Magazine.  We’ll also be joined by special guest Dave Baker, a longtime friend and industry colleague from PwC.

We’ll review the findings from the A&G 2011 Year-End Survey, discuss trends we see shaping the role of enterprise architect going in to 2012, and answer listener questions.

Follow this link to the Architecture and Governance Website for more information and to register.


A Question for Practicing EAs

November 7, 2011

Why are you doing enterprise architecture?

If you don’t know the answer to this, how can you expect others to understand EA?

This is a simple question, but we are looking for comments from your readers to help others (without their answer) come up with the answer that meets their situation.  While everyone probably has a unique approach to the process, organization, and deliverables for EA; we find that the objectives of EA are similar across organizations.  You may not currently be fulfilling the reason why you are doing EA, but you have to at least know what you are TRYING to do.

Let us know by your comments, Why are you doing enterprise architecture?


Tim Westbrock to Speak at IT Leadership Forum, Dec. 13, in Atlanta

November 7, 2011

Join Tim at the IT Leadership Forum, Dec. 13, in Atlanta, sponsored by alfabet.

Tim will be presenting “Expanding Enterprise Architecture into the Business.”

The ultimate promise of Enterprise Architecture has always been the alignment of business and IT strategies, activities, assets and direction.  In order for EA to bridge the gap between the desired business future state and the work that must be done to achieve that future state, EA must evolve to include a business architecture sponsored by business leadership and developed by business professionals.

Tim will facilitate a discussion on the many facets of business-enabled EA, while also adding their experiences relating to the challenges of approaching the business, how EA and ITA work together, the goals, organization and outputs of a business enabled EA approach and how to get started.

This is an invitation-only event, so if you are going to be in the Atlanta area Dec. 13th, click here to get more information on the event and how to register your interest in attending.

Hope to see you!


Too Much Tactical Focus with Business Architecture?

July 12, 2011

As more and more organizations embrace Enterprise Architecture with a concerted effort in Business Architecture (BA),. we are beginning to see one of the common pitfalls of IT Architecture (ITA) spill over — too much focus on the tactical, project level.  Apparently, getting business representatives involved in applying EA discipline to the business architecture does not mean that the effort will remain high level, strategic and forward thinking.  Just like many ITA efforts, BA efforts result in the identification of work that needs to be done to support the enterprise’s transformation.  And also like many ITA efforts, once the resulting work is started, many of the BA participants find themselves involved in the transformation effort.  Another factor that needs to be considered is the lack of dedicated BA resources, such as a Chief Architect or Business Architect or BA team.  The BA efforts are usually staffed entirely by a virtual team, all of whom have real, demanding full-time jobs.

If you are trying to avoid an overly tactical focus for your BA efforts, here are some suggestions to consider:

  • Dedicated BA Resource.  A dedicated resource, not assigned to specific BA initiatives, but also not holding a full-time non-BA position is probably not feasible in many organizations.  However, those going through significant transformation efforts could easily justify a resource to keep pushing the transformation agenda, overseeing the BA initiatives, maintaining a focus on future change, and organizing and managing the BA virtual team.  If a full-time dedicated resource is not feasible, consider finding a leader who can dedicate some time to the effort, 25-40% minimum, while not getting deeply involved in individual BA initiatives.
  • Strategic Agenda Items for Regular Meetings.  Most BA groups have regularly scheduled meetings, weekly, monthly, bi-monthly, etc.  By having every third or fourth meeting focused on new strategies, new technologies, new changes, rather than ongoing initiatives; the group will still be able to push the transformation work forward, while also continuing to architect the future business.  Another alternative is to always have at least one agenda item that is of a strategic, future oriented topic at each meeting.
  • Maintain a Portfolio vs. a Project Perspective.  Rather than providing oversight to individual projects and implementation initiatives, focus on providing input to the investment decision-making function(s) of the enterprise, and track the overall portfolio’s progress against expected strategic outcomes.  Leave the cost, budget, resource, and schedule issues to the project management staff.

All of these suggestions are not new.  They are the same kind of actions that successful ITA groups have been employing to maintain a strategic perspective for years.


Follow

Get every new post delivered to your Inbox.