What tips do you have for someone just starting out in Enterprise Software architecture?

There is a proven causation between having structured, clear, written and signed off requirements and delivering on time, scope & budget. Separately, understanding (and modelling) vision, mission, objectives and goals and how those relate to strategic initiatives help inform investment planning so that we engineer requirements for the right opportunities in the first place.

Even if you get all the requirements in writing and buy in from business, engineering and other stake holders, you need to build in flexibility. You are lucky if you can build 80% of what is needed today, and needs are 100% likely to change shortly after deployment. The flexibility to accommodate future needs is often overlooked and costly to fix.

Get hands on experience with the existing product if possible and make sure you truly understand use cases and business requirements to ensure alignment of the design from the beginning. This will have a great effect in having well designed and coded solution as opposed to overly complicated, patched up solution with gaps that needs to be heavily refactored. Make sure design is up to date and well understood by the stakeholders.

Understanding the business objectives and the current IT landscape is essential to identifying the pain points experienced by both business and IT departments. The significance of enterprise architecture lies in its ability to address technology-related problems through a business-focused lens.

In my experience, one of the most difficult aspects is understanding the company's culture and how it drives strategy. A fast-moving culture will have little patience for an architect who waits for business stakeholders to have a clear, complete set of requirements, whereas in a consensus-driven culture, the architect must spend time with the hidden influencers as well as the nominal stakeholders and be prepared for priorities to shift in the background.

Knowledge of architectural patterns and ANTI patters is important, it’s like knowing the symptoms in medical profession. Knowledge of patterns should not be limited just to technology patterns but understanding of organizational behavior patterns, management trends, anti-patterns caused by Organization’s operating model/structure /restructure also plays an important role in making architecture decisions.

A Choice of the appropriate architectural style and patterns for enterprise software is important for ensuring scalability, flexibility, maintainability, and other attributes. There are some common architectural styles and patterns used in enterprise software development: -Service-Oriented Architecture (SOA) -Microservices Architecture -Event-Driven Architecture (EDA) -Layered Architecture -Hexagonal Architecture (Ports and Adapters) -Event Sourcing and CQRS (Command Query Responsibility Segregation) -Model-View-Controller (MVC) -Repository Pattern -Component-Based Architecture

Every architecture pattern, independent of its name, should aim to resolve the business requirement. And it really depends on the types of events, the flow of processes or documents or interactions in a given system, the desired outputs, among other things. We must put aside any emotional attachment to specific frameworks or technology and aim for what is the most understandable, objective, safe and precise architecture.

Leverage your current and soon to be vendor partners that might touch the product or project. Ask your security sales teams for example, who else is doing something like this in your customer community. Could you host a dinner or set up a Zoom for us to get some feedback from them on their experience with your product working in an environment like we are looking to develop.

Pour une bonne architecture logiciel dans l'entreprise, il faut commencer par une bonne stratégie MAKE or BUY qui s'appuie sur des critères concrets tels que l'application doit-elle répondre à des besoins standards sur la marché ou est-elle au coeur de la proposition de valeur de l'entreprise pour laquelle on veut une ma?trise complète ou est-ce un brique technique (comme l'authentification) qui doit répondre à des standards mais aussi des bonnes pratiques pour assurer la sécurité. Il existe des grilles qui permettent selon notre cas de figure d'établir la bonne stratégie pour soi. C'est important car cela guidera considérablement les choix d'architecture logiciel et d'intégration.

Dont ignore the necessity of change (of everything) - defining a lifecycle of the overall solution as well as the integral but interdependent elements is vital IMHO - software, firmware, security and governance requirements all change over time and very often more quickly than initially thought = plan for it in an overall process that includes the sub elements.

And remember - you should document what are you doing. If no-one else it is clearly YOUR responsibility to document what and WHY are you doing

Il y un aspect crucial à envisager lorsque vous concevez une application constituée de microservices ou petits services bien circonscrits fonctionnellement, cela concerne le pilotage des traces (lors de l'étoilement des requêtes entre tous ces services dans le cadre d'une transaction) et des logs. Le monitoring et la maintenance efficace de l'application notamment dans le diagnostique d'incidents est à ce prix

Modularity is key to any large system. That said a healthy dose of common sense is needed to balance the need for modularity and maintainability. Sometimes too many moving parts is much harder to maintain than fewer moving parts with focussed function and some duplication. Follow the 80 - 20 rule.. Nothing is perfect and keep that in mind. In enterprise software you build for when you will no longer be there to explain why you chose a particular approach.

1) Identifier la ou les activités de l'entreprise 2) identifier les process de la vente à la livraison 3) identifier autour des flux, les logiciels utilise Il en découle l'architecture fonctionnelle et l'architecture technique.

One of the most fundamental things that architects do is to evaluate options, impacts and create decisions. Collaborating with your strategic stakeholders, you must fully understand and prioritize the major quality attributes you are designing for, using mechanisms like a quality attribute utility tree. With this information you can conduct proper architecture tradeoff analysis, understanding that sometimes there are mutually exclusive goals (ie performance vs modularity). With your prioritized quality attributes guiding these tradeoffs, you can make the architectural decisions that align best to the overall goals of the initiative.

All architecture must be guided by business objectives, company ecosystem, and a solid business case that confirms the value in that architecture. There are many ways to accomplish a given objective but knowing what the business objectives are, the capabilities of the company to support specific directions, and the value returned for any given direction allows for the 'best' solution amongst alternatives.

Internal and external qualities can be categorized into: Functionality (suitability, accuracy, interoperability, security), Reliability (maturity, fault tolerance, recoverability), Usability (understandability, learnability, operability, attractiveness), Efficiency (time behavior, resource utilization), Maintainability (analysability, changeability, stability, testability) and Portability (adaptability, installability, co-existence, replaceability). The primary purpose of evaluating or establishing internal metrics is to ensure the expected external qualities can be achieved and satisfy the quality in use (effectiveness, productivity, safety, and satisfaction).

You may know how to produce the most sophisticated diagrams and design documents, but if your team members or stakeholders are staring into the abyss when looking at your artifacts, you're letting them know how smart and talented you are, but you're not doing your job of effectively communicating important design decisions. Sometimes you will need to communicate in different ways to different people to get your ideas across.

Focus on outcomes required for the downstream activities and speak the language others can understand. Learn to use software tools that can automate the enterprise architecture process.

As I specified in my perspectives in 1) Understand Business Goals and 3) Apply Modularity principles understanding the business , the way users use the applications and the gaps that exist in their current architecture are important elements when documenting. The other reason to document is that you are ensuring that those that follow understand the reasons for architectural choices and the rationale for choosing a particular path. Enterprise architecture is about building for the long term and documentation helps that journey

If you don’t have budget or can’t get approval for a full time hire to help document, ask if you can use Fivver. Fivver is proving to be a great resource for very capable (read the reviews) talent like a technical writer, who can help document during the duration of the project.

My trainers always tell me that if what I am communicating is not understandable by my grandmother, then I have failed. Of course this is an exaggeration but the point is make anything you need to explain as simple as possible. A complex matter such as architecture needs not be made into a auper rocket science matter.

* Study the project time frames and requirements * Study and understand compliance requirements * Know the existing contracts and terms with providers, they drive outcomes too * Understand the brown field in front of you because it's not all theoretical green field

Brian is absolutely correct - beyond my thoughts on life cycling keep looking forwards because no project I have ever worked on has been delivered looking as it did when first conceived; similarly two or three years later interdependencies change; synergies not available at inception are often not only viable now but essential that they be included.

Some of the best designs are often iterative. Don't just assume that the way it was done before was stupid, but try and understand why certain decisions were made. Then you can re-evaluate based on the design goals and changes in the technology landscape to help guide people involved in the previous decisions without isolating them. It's always better to ask questions and seek to learn rather than assume a particular approach is the best or only way.

3C and 3P : Expertise about Code, Components and Complexity is important to be an effective architect, however having good understanding of 3Ps - People, organizational Politics and Paisa(Penny) will definitely make one a good architect.

Keep an open mind and not focus on preconceived notions. Listen to everyone's ideas before making an judgement calls. One can never predetermine where the next positive impact will come from.

If someone is starting fresh in Software Architecture, he may not understand the architectural patterns, architecture requirements etc. What he needs to work on is that he should be able to understand the business problem and look at the bigger picture and try to solve the problem. Rather than tactical approach, he should focus on strategic approach. Most important in building architecture is the architectural approach and other things come later. One you are able to define the approach, you will be able to establish your own patterns eventually.

Many answers here seem to answer a corresponding question about IT Architecture or Solution Architecture - not Enterprise Architecture. My number one recommendation about EA is to learn The Zachman Framework. Instead of being concerned about one EA methodology or another, you should understand the basic components and structure of EA. This will help you understand the individual pros and cons of the different EA methods, and even make you able to develop your own EA methods suited for working with the tasks you are assigned in your work. It would be wrong to solve all EA problems with the same EA methodology, such as TOGAF.

Stick to the altitude of enterprise architecture instead of being sucked into the loophole of to many details. You’re working on the entire enterprise and not a single solution. Keep this in mind. Additional you don’t need to be a specialist in any field you’re working on. You need to have a wide range of knowledge and less special deep dive knowledge. If you have to much to share on a special topic you’re probably a better domain, solution or software architect