I always enjoy working with organizations’ Enterprise Architects. When they execute correctly, enterprise architects truly shape the direction of the organization. They touch everything, including how corporate governance should function, where the business needs to move in terms of process and performance, how information management should be improved, what the key information technology initiatives should be, and how the portfolio should be shaped to support this to-be vision. Enterprise architects are usually passionate individuals, truly devoted to their chosen Enterprise Architecture framework, tool, and population methodology. They should have this zeal; they weave together the entire disparate threads of the organization. The best organizations leverage their enterprise architecture to foster making and executing on key business decisions. When I sit with enterprise architects for the first time, I’m usually given a slide show overview of what the architecture is all about. Sometimes, I’m shown actual artifacts, and rarely, they’re pulled up directly in the architecture tool. When it’s time for questions, I intentionally lead with one that always returns blank stares: “Do you have any automated tests?” I don’t expect a response, and usually I’m looked at strangely. I do believe strongly in the question though, because it makes them realize that there’s a potential deficiency in their architectural approach. If I thought they had considered that question already, I’d ask, “How do you approach creating your automated test-driven enterprise architecture to ensure it’s executable?” Automated test-first development is found throughout the Agile software development practice; it can also be found to some extent by Business Process Management (BPM) practitioners when creating simulations in a BPM tool. It’s the process of creating a small, discrete automated test in advance of the solution (such as source code) being present. When executing the test initially, therefore, it will fail as there is not yet anything to execute. Over time, as the solution is created, the test passes. The tests are then packaged to continuously run in an integration build. If a test begins to fail, it’s either that the implementer made an error, or the underlying intent has changed and the test needs to be updated. In either case, the implementer is forced to think about the reason for the test’s status change. Automated tests can be created for an enterprise architecture throughout its development process in many areas. A basic one is the population of an artifact. For example, let’s say the architecture contains a taxonomy of governance bodies, each which is tied to one or more business processes which, in turn, are tied to one or more web services. The automated tests, possibly leveraged as macros in an enterprise architecture tool, are very straight forward:
Is the desired core information present for the entered governance body such as its name?
Is the governance body linked to at least one corresponding valid business process?
Are each of the web services linked to one or more business processes?