Download Enterprise Architect 16 Full Crack
Rancul Ratha
Kevin Hickey has a passion for helping enterprise organizations find practical applications of agile and lean practices. He has experience leading software delivery as a developer, architect and project manager. He is currently a Technical Principal at Thoughtworks.
If you are an Enterprise Architect (EA) in an organization transitioning to lean or agile practices, you may be feeling a bit lost. You have worked hard to get where you are. You probably wrote most of the critical system software keeping your enterprise running. You helped implement and maybe even designed the architecture. You know some of it is older technology and a bit fragile, but with too few resources and too little time, compromises have to be made. In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers routinely work around the system, complaining that process holds them back, but you know that these things are there for the good of the company so you reinforce the policy to try to keep control.
Overall, this is a shift from the traditional practices of the EA and architecture team. Instead of a centralized EA group making decisions for the development teams, you are now an influencer and aggregator of information. Your role is no longer to make choices, but to help others make the right choice and then radiate that information. Doing this requires some new tools and techniques. Following are some ideas on how to act in this new role. All of them are high level and do not all apply to every organization. The goal is to be nimble and responsive to the needs of the teams you support; experiment with some techniques, measure their effectiveness, keep the ones that work and pivot on the ones that do not.
A first and important step to promoting consistency is having a long-term vision for the enterprise portfolio. Being able to describe both the current state and future state architectures is essential to bringing projects in line. Start by assessing the current portfolio. Map out what systems exist and what they do. This does not need to be deeply detailed or call out individual servers. Instead, focus on applications and products and how they relate. Multiple layers may be required. If the enterprise is big enough, break the problem down into functional areas and map them out individually. If there is an underlying architectural pattern or strategy, identify it and where it has and has not been followed. For example, if the enterprise strategy is a Service Oriented Architecture, which applications work around it and access the master data directly? Where are applications communicating via a common database?
Once you have the current state mapped out, think about what you would like the architecture to look like in the future. Do you want to keep the same underlying strategy? Would it be better to pivot to a different model altogether? What are the strengths and weaknesses of your current strategy? If you want to evolve the current strategy, produce an updated view of the architecture where the inconsistent areas are made true with the rest. If you think that a wholesale strategic change is necessary, map out what the ideal end-state would look like. Understand that this is a long range vision but one that you want the rest of the technology group to follow.
When you feel some level of consensus, make the current and future state architectures visible. This does not mean in a folder on a drive or a Sharepoint site or a Wiki. Make posters or wall size printouts. Display them in multiple areas. The goal is to make sure that everyone can share the vision and continue to move towards it. As the architecture evolves, update the visuals to reflect the work done and any change in direction. Show where improvement is being made and acknowledge the teams that are making it. Help others have pride in coming together to build something great and they will support it.
Once you have a vision, you want to see it come to life. But since you and your team are not developing or managing projects, how can you make this happen? The best way is become a partner and resource for the development teams. Your purpose is not to limit or block progress but instead to enable it. When a development effort is starting, reach out to the technical and project leadership. Offer them a refreshed view of the target enterprise architecture and discuss how their project can enable that vision. Often times teams are engaging in work that is similar to other ongoing or completed projects in the enterprise. Make sure that they are aware of these projects so that they can leverage anything from shared experience to actual code and artifacts. Try to avoid getting mired in the details of the implementation; do not worry about what libraries or versions are going to be used. Focus instead on the high-level goals and design of the project and how it aligns to the overall vision.
When discussing projects, inevitably technology choices will come up. Most of the time teams are content to use similar technologies to other projects in the enterprise. Occasionally, however, technologists learn about a new technology and want to use it to solve their problem. Avoid the temptation to immediately say no or assume that they are selecting the new tool just because it is new and fun. While that can and does happen, new tools are created to solve problems and it might just be the right time to move forward. Discuss the choice with the technology team to determine if they have a good argument for using the new technology. Make sure they understand the cost and difficulty of bringing a new platform to production and that the benefits outweigh this cost. You may have to listen for a bit then do some research before finishing the discussion. Consider doing a time-boxed proof-of-concept with real measurements and boundaries to determine the feasibility. If, in the end, the new technology is not the right choice, try to gain consensus from the developers or their leadership. Avoid making it a mandate if at all possible. This will help generate good will with the development teams and ensure that they will include you in future decisions. When experimenting with new tools or technologies, limit the number of experiments ongoing in the enterprise at any one time. It will be hard to measure the effects accurately with too much simultaneous change.
Ultimately, success as an EA is only made possible with the support of the development teams. If you treat them like subordinates they will find ways around you and put your vision and strategy at risk. You will still be held accountable for the outcomes with little ability to change them. If, instead, you treat them as partners they will help you realize your vision and everyone will get to be successful. Embrace change but measure it and make sure that everyone understands the value of the change. Ultimately, always try to guide teams to the vision of the enterprise architecture.
Big change takes time and opportunity. Once you have your vision for the future and start to build excitement within the enterprise, you will want to see results immediately. It is important to keep in mind that big changes in architecture need to come gradually and at the right time. Use existing projects in the portfolio to start the process of change. Guide new implementations to move toward the architectural vision. Keep in mind that opportunities to change code and move in the desired direction may not come at the speed or in area that you want them to. Learn to celebrate the victories, however small, and stay vigilant for chances to make positive change.
That being said, work with the business to prioritize projects that address the worst parts of the existing portfolio. Business leaders rarely understand the value of changing technical components nor the cost of maintaining the status quo. When purely technical changes are warranted, it will fall to you to create opportunities to change them. Make sure to frame the change in terms of value to the business in future savings offsetting the cost to implement or in terms of risk reduction. If necessary, find a partner in a business function and create a project that both adds new business value and enables a change in architecture. Seek opportunities to retire old applications and hardware that are a drag on the budget and operations teams.
In addition to having a vision for the overall enterprise architecture, it falls to the EA to see that vision executed with the right skills and practices. While each development team will develop the skills it needs to succeed, sharing the best skills and practices across different teams will help each of them execute better and have a shared sense of purpose. As the bridge between teams, you are best suited to fostering this sense of community.
They drive design, engineering, reuse, application of patterns, and create Enabler Epics for the architectures that comprise the solutions in a portfolio. Relying on continuous feedback, these architects foster adaptive design, and engineering practices, and drive programs and teams to rally around a shared technical vision.
In Portfolio SAFe and Full SAFe, the architectural challenge is even more significant. Mergers and acquisitions, changes in underlying technologies, competitive differentiation, emerging standards, and other factors often push businesses in directions beyond the scope of Agile Teams.
Enterprise Architects provide strategic technical direction across value Solution Trains and ARTs to ensure the organization can take advantage of emerging opportunities while responding to and mitigating threats. Aspects of this strategy may include recommendations for the development and delivery of technology stacks, interoperability, application program interfaces (APIs), and hosting. They also apply a Customer-Centric mindset to their work when considering architectural choices. For example, APIs are an interface that benefits from the application of Design Thinking practices, such as using developer personas.
08ab062aa8