Proper selection of technological platform is essential for projects' success. Based on functional and mainly on non-functional requirements, one has to consider scalability, performance, security, flexibility and other issues of planned software product. The endeavour can be complex, unless we are guided by some methods and best practices. Sometimes enterprise enforces usage of an appropriate enterprise platform or database systems. Additionally, enterprise may have support and delivery contract with one single vendor, prescribing low level architectural components.

Usage of such method and supporting tools as TOGAF for developing of enterprise architecture enables a vision of architecture based on enterprise level abstraction and without dealing with concrete architecture instance. Thus one can describe Architecture Vision, Business and Information System and Data Architectures in abstract and reusable building blocks and select afterwards a Technology Architecture. For example, one can define a collaboration contract for extended enterprise (the one that includes partners, suppliers, customers as well as internal business units) using SOA pattern, without dealing initially whether the underling platform will be JEE or .NET based. Enterprise architecture is aimed to optimize the fragmented legacy of processes across the enterprise into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

TOGAF and Scrum are flexible frameworks for up- and downsizing. Both stress the business value and iterative processes. Both have inspect and adapt phases. Main difference comes from envisioning cycles and different focus on deliverables scale. Large enterprise with multiples teams and hundreds of projects will unavoidably come - may be with help of some ad hoc improvement community - to the idea of reusable building blocks (software artefacts or components) in an enterprise repository of some kind for possible future re-use increasing in so doing othe verall ROI of each delivery cycle and providing more transparency on enterprise level. Best way of thinking would be to upsize SCRUM to TOGAF trying to overcome some terminological prejudges on both sides.

One of interesting differences between TOGAF and SCRUM is that SCRUM framework, as described in the Scrum Guide, should be immutable for delivering of best results. Different implementations (e.g. burn down or burn up charts, index cards, user stories estimation in ideal days of in T-short size) are considered secondary and depend on projects circumstances. TOGAF could be und in many cases possible will be customized. During application of TOGAF to a project customization level, documentation and ADM cycle should be considered.