Article Types and Submission Process
Enable Architect welcomes original articles from the perspective of architects in technology-centric roles. This includes a wide variety of topics on technology, career development, productivity, and more. We can also republish articles with an author's permission from their personal blog, LinkedIn, Medium, or similar site; we don't republish articles from vendor blogs. If you want to write for us, please see our contributors page to get in touch with us.
The following sections describe the different types of articles that a contributor can create for Enable Architect. The article types are intended to be suggestions to help scope a proposal. Different forms of submission are welcome. These types of submissions tend to be faster to process and publish, which has its advantages.
A news piece reports a recent event, technology, or technique relevant to enterprise architecture. It answers the six basic questions asked when reporting on a topic: Who? What? When? Where? Why? How?
The writing style should be concise yet engaging and focused on presenting the facts at hand. Typically, these articles are ~500 words in length.
An important note for all articles for this audience: no architectural news or consideration is either "good" or "bad." Consider all tradeoffs, and provide viable architectural scenarios throughout the article where those tradeoffs are relevant.
Example: Examples of edge computing: how cloud architects are benefiting from cloud-to-edge architecture
An opinion piece expresses a point of view or impression of a practice, technology, or technique relevant to enterprise architecture. Its role is one of personal connection: authors are encouraged to use the first-person ("I" statements) or speak to the readers directly ("you" statements). Typically an opinion piece is between 500 and 750 words in length.
Any arguments or assertions made in an opinion piece must be justified by facts and examples. The topic or thinking presented in an opinion piece can be strongly held, though all writing must be polite (as we outline in our guidelines).
Also important to note, Enable Architect prefers vendor-neutral topics. For instance, suggest a necessary functionality to a solution rather than propose a specific vendor solution or tool as the only optimal answer.
Example: How I became a Data Architect or What type of Data Architect should you hire?
A step or listicle piece is segmented into a series of steps or list items that are focused on a specific topic. The piece should have a short introduction that provides context to the content and a conclusion that reiterates the main takeaways. Each item in the list should be described using short, engaging language.
This format can be incredibly effective for providing context for those new to a concept or technology. Typically these articles are between 500 and 750 words in length.
Example: 5 processor architectures making machine learning a reality for edge computing
A didactic/instructional piece teaches the reader how to do something relevant to enterprise architecture.
The language needs to be clear and unambiguous. Writers are encouraged to use illustrations to reinforce the concepts and techniques described in the piece. Didactic/instructional pieces are typically between 500 and 1500 words in length.
Example: How to get hired as an Enterprise Architect in 2021
An analysis piece investigates a technology or process and then provides commentary about the topic of interest. Typically an analysis article is between 500 and 1500 words in length.
It is recommended that you analyze a technology or process in terms of benefits and challenges. Analysis pieces tend to be read by architects who are considering or in the process of adopting a technology and want to get a balanced, informed assessment of the subject at hand. Note that we do not accept product reviews, but we are interested in a discussion of a product's architectural pattern.
Example: Architectural messaging patterns: an illustrated guide
Architects' guides provide a thorough investigation of a topic designed to be a key resource for one or more types of IT architect. Typically guides are 1000 words or more in length.
It is recommended to crisply scope the level of abstraction the guide intends to explore. For example, if a guide explores load balancing architectures, it will not also guide a user into deploying a load balancer (the latter being a separate article from the former). Guides, like all deep explorations on Enable Architect, discuss a technology or process in terms of benefits and challenges.
Guide pieces tend to be read by architects that are looking for a canonical reference and want to get a balanced, informed assessment of the subject at hand. Note that we do not accept product guides, but we are interested in a discussion of a product's architectural pattern.
Example: An Architect's guide to APIs: SOAP, REST, GraphQL, and gRPC
Some potential authors submit complete drafts to Enable Architect, while others request guidance on formulating a topic and writing their draft. We welcome both types of submissions.
The following illustration describes Enable Architect's process for escalating an article from contributor concept to published piece (steps 1–4 apply more to people seeking more input in the early writing stages). The details of each phase in the process follow.
1. Identify topic with a working title
The contributor identifies an article topic and creates a working title for the intended piece and anticipated word count. The important part of this phase is a clear pitch: What do you want to cover and does it fit any of the patterns above?
2. Enlist editorial support
The contributor reviews the plans for the intended article with an Enable Architect editor. The editor will provide support in terms of consultative guidance, organizing the article, and creating the content of the intended article, if the contributor desires this assistance.
3. Decide on draft delivery date
The editor and contributor will decide upon a delivery date for a draft submission of the intended article. The editor will provide regular reminders if it supports the author's personal goals around publishing an article.
4. Create a general outline
The contributor creates a general outline of the intended article. The outline should have at least three first-level headings and include an introduction and a conclusion.
5. Write a draft
The contributor writes the draft, with editorial support, if so desired.
6. Submit a draft
The contributor submits a draft of the article to the editor. The contributor notifies the editor that the draft is ready for review.
7. Technical edit
The submission is reviewed by a technical editor for technical clarity and accuracy. The editor communicates with the author if there are any questions and/or to notify the author whether the article will be accepted.
8. Copy edit
The submission is edited by a copy editor for spelling, grammar, clarity, and conformity to the site's editorial style.
9. Contributor review
The edited draft is entered into the Enable Architect content management system (CMS). The contributor is notified that the submission is ready for final review. The contributor reviews the work for accuracy in terms of intention and information and notifies their editor of any changes that need to be made.
Contributors are responsible for approving the wording used in their article, and editors have the final say on the title and URL.
The managing editor sets a publication date for the submission. We will do our best to keep the author informed about the final publication date and initial readership, though we may need a reminder from the author.
Congratulations, you're officially a published author on Enable Architect!
We will share your work across available channels inside and outside of Red Hat. Authors are encouraged to share their articles across their networks as well.